| 03:59 | <JonathanNeal> | hello |
| 08:37 | <tantek> | thanks MikeSmith for the #microformats edit - I've been unsure about the rel-publisher value since I saw it show up. |
| 08:43 | <MikeSmith> | tantek: somebody asked about it on the www-validator list (asked why the validator doesn't support it despite it being on the wiki page) |
| 11:52 | <annevk> | oh, seems some of the IETF found the URL Standard again |
| 11:52 | <annevk> | too bad their comments are not really actionable |
| 12:04 | <odinho> | What are they saying? |
| 12:06 | <annevk> | https://twitter.com/bagder/status/286544650284699648 |
| 12:09 | <annevk> | I like this one too https://twitter.com/dret/status/286625563496574977 |
| 12:09 | <annevk> | Especially combined with the fact that their hero Roy has been stating that URI == URL for some time now... |
| 12:10 | <annevk> | Anyway, back to creating more states for more sensible error reporting... |
| 12:40 | <annevk> | If you resolve http:example.org against http://example/ should that give a parse error? |
| 12:43 | <annevk> | I'm going with yes... |
| 12:55 | <odinho> | Hehe. One thing they do say though, is that it would indeed be nice to have a non-normative overview over what's supported. You're doing lots of findings, and then encode them into this spec, but it's not quickly referencable. Although I fear that would be too big to use in the end anyway... |
| 12:56 | <annevk> | Given that it all changes over time I don't really see how that's useful. Although you could "generate" such a thing if we completed that test suite... |
| 12:56 | <annevk> | Sorry, I can see how it's useful, but also how it'd be time consuming :-) |
| 12:58 | <odinho> | Yeah. |
| 13:56 | <SimonSapin> | annevk: maybe diagrams like http://dev.w3.org/csswg/css3-syntax/#token-diagrams would help explaining the syntax of URLs? |
| 14:00 | <annevk> | SimonSapin: yeah, the plan is to add those at some point |
| 14:00 | <annevk> | SimonSapin: though the comments were about parsing |
| 14:38 | <annevk> | SimonSapin: those syntax diagrams seem incomplete btw |
| 14:38 | <SimonSapin> | annevk: how so? |
| 14:38 | <annevk> | SimonSapin: e.g. for url() you can also escape the u / r / l |
| 14:39 | <SimonSapin> | indeed |
| 14:44 | <SimonSapin> | annevk: or maybe not. http://www.w3.org/TR/CSS21/syndata.html#tokenization uses "url" litteraly in the token definition, not something like {u}{r}{l} |
| 14:44 | <SimonSapin> | Green in Firefox and Opera but Chromium: data:text/html,<style>@import \75rl("data:text/css,body{background:green}") |
| 14:50 | <annevk> | SimonSapin: yeah, the old specs are messy that way |
| 14:51 | <Ms2ger> | Sounds like something needs a test |
| 14:51 | <annevk> | SimonSapin: there was a problem of sorts with writing it as {u}{r}{l} if I remember correctly |
| 14:51 | <SimonSapin> | annevk: http://dev.w3.org/csswg/css3-syntax/#data-state still does not allow escapes |
| 14:52 | <annevk> | SimonSapin: oh Tab forgot the hard part? |
| 14:53 | <annevk> | oh I see |
| 14:53 | <annevk> | hmm |
| 14:57 | <SimonSapin> | seemed deliberate to me last time I looked, but maybe |
| 14:57 | <annevk> | yeah, seems weird though to accept escapes everywhere but url() |
| 14:57 | <annevk> | well and @charset, but @charset is weird |
| 14:58 | <Ms2ger> | Ah, darobin is back? |
| 14:59 | <SimonSapin> | I don’t think this is really a problem in practice. Have you ever seen escapes used on CSS-defined keywords, other than in test cases? |
| 14:59 | <SimonSapin> | But yes, it should be clarified |
| 15:00 | <annevk> | well I'd prefer if we killed CSS escapes |
| 15:00 | <annevk> | especially for keywords/identifiers |
| 15:00 | <annevk> | but that seems unrealistic |
| 15:00 | <darobin> | Ms2ger: ayup |
| 15:01 | <Ms2ger> | darobin, go review some tests :) |
| 15:01 | <darobin> | thanks for the pull requests wrangling you did over the holidays |
| 15:01 | <darobin> | haha |
| 15:01 | <darobin> | will do, but I'm still catching up on email |
| 15:01 | <SimonSapin> | annevk: probably unrealistic. But I usually pretend they’re not there. Just like I pretend that everything is case-sensitive ;) |
| 15:02 | <Ms2ger> | Good :) |
| 15:02 | <Ms2ger> | I've got some more pull requests to create, but branches hurt my head, so it'll be one at a time |
| 15:17 | <annevk> | SimonSapin: if only we could go back in time and simplify some of this stuff |
| 15:17 | <SimonSapin> | annevk: @charset is case-sensitive too :) |
| 15:17 | <annevk> | SimonSapin: @charset is beautiful |
| 15:18 | <annevk> | SimonSapin: requires double quotes as well |
| 15:18 | <annevk> | SimonSapin: and a single space preceding the double quotes |
| 15:18 | <SimonSapin> | and a single space, no comment, no space before the ; |
| 15:18 | <annevk> | yeah, once you have to write out the details people suddenly realize they should keep it simple... |
| 15:19 | <SimonSapin> | well, if we go back in time let’s support UTF-8 only, @charset doesn’t even exist |
| 15:19 | <annevk> | fair point |
| 15:19 | <annevk> | and kill utf-16 before hsivonen et al get a chance to be upset by it |
| 15:19 | <SimonSapin> | hehe |
| 15:23 | <annevk> | how many days left in this TAG election thingie darobin? |
| 15:23 | <darobin> | 6 |
| 15:23 | <SimonSapin> | wrote to www-style about escaping url() |
| 15:23 | <annevk> | so it's closed after Jan 9? |
| 15:24 | <annevk> | SimonSapin: might want to search the archives |
| 15:24 | <annevk> | SimonSapin: Bert and I went over it before... |
| 15:25 | <annevk> | SimonSapin: http://lists.w3.org/Archives/Public/www-style/2007Dec/0215.html |
| 15:26 | <annevk> | SimonSapin: http://wiki.csswg.org/spec/css2.1#issue-23 |
| 15:27 | <annevk> | SimonSapin: it was closed, but no idea how it was fixed (assumed editorial suggests they agreed with {u}{r}{l}...) |
| 15:27 | <darobin> | annevk: yes, correct |
| 15:32 | <SimonSapin> | annevk: http://test.csswg.org/suites/css2.1/20110323/html4/uri-015.htm |
| 16:15 | <annevk> | SimonSapin: the assert there is wrong |
| 16:15 | <annevk> | metadata fail #nobodyiscounting |
| 16:19 | <annevk> | SimonSapin: see also e.g. http://www.w3.org/TR/2010/WD-CSS2-20101207/grammar.html#scanner |
| 16:20 | <annevk> | SimonSapin: stuff changed there, I forgot if there was an email explaining why |
| 16:20 | <SimonSapin> | annevk: lots referenced from http://lists.w3.org/Archives/Public/www-style/2012May/0329.html |
| 16:20 | <SimonSapin> | I’m writing a patch for css3-syntax |
| 16:22 | <annevk> | SimonSapin: except the edit was made and then reverted, and I believe Bert had a reason for that |
| 16:22 | <annevk> | SimonSapin: see the above draft for where the change was actually in |
| 16:31 | <annevk> | Ah, the problem is http://lists.w3.org/Archives/Public/www-style/2010Jul/0499.html I suppose |
| 18:38 | <SimonSapin> | annevk: well, in level 3 tree construction actually uses the tokenization |
| 18:38 | <SimonSapin> | having a full CSS 2.1 separated from the core grammar was a mistake IMO |
| 18:46 | <annevk> | uhuh |
| 19:26 | <Ms2ger> | w3fools is down? |
| 19:55 | <Hixie> | annevk: https://twitter.com/dret/status/286625563496574977 is funny because that's what people from the w3c said back when we started with Web Forms 2 :-) |
| 19:55 | <yroc> | Hi, happy new year all -- wondering about rationale for <pre> |
| 19:56 | <Hixie> | anything specific about it? or just why it's in the spec? |
| 19:56 | <yroc> | why not just use white-space: pre; |
| 19:56 | <yroc> | and display: block; |
| 19:56 | <tantek> | because the white space has meaning in the content sometimes |
| 19:56 | <Hixie> | the idea is that CSS is optional |
| 19:56 | <yroc> | on any particular element that you want preformatting? |
| 19:57 | <Hixie> | you should be able to get everything important even if the CSS doesn't get applied |
| 19:57 | <tantek> | e.g. code, python, etc. |
| 19:57 | <tantek> | if the whitespace has meaning, use <pre>, if the white-space is presentational, use white-space property |
| 19:57 | <Hixie> | tantek: yroc is writing our rationale document, so he needs the "why" more than the "what" :-) |
| 19:58 | <tantek> | Hixie, s/important/has meaning in the content |
| 19:58 | <tantek> | "important" is too fuzzy / not actionable |
| 19:59 | <Hixie> | yeah not saying what i said was good, just that "do X" isn't helpful if the question is "why do we have X" :-) |
| 20:00 | <tantek> | my answer was for why |
| 20:00 | <yroc> | But really, where do we stop adding elements then. What makes preformatted text special enough to be given (and retained) a semantic tag? |
| 20:00 | <tantek> | we have <pre> because there are cases where whitespace has meaning in the content. |
| 20:00 | <tantek> | yroc - elements have to meet a certain high bar for inclusion. I believe W3Cmemes has an explanatory image for this. |
| 20:00 | <yroc> | Or is it just historical? |
| 20:00 | <Hixie> | yroc: realistically, we have <pre> because it was implemented already when i wrote hte spec |
| 20:01 | <tantek> | (new) elements |
| 20:01 | <yroc> | Hixie: right then, it's basically historical... |
| 20:01 | <Hixie> | yroc: and for things that were implemented already, the choice is either (a) drop it in the "obsolete" section or (b) go all-in and spec it properly |
| 20:01 | <tantek> | Hixie, more stuff should have gone into the obsolete section |
| 20:01 | <yroc> | @So what made you decide the latter for pre? |
| 20:02 | <Hixie> | yroc: for <pre>, (b) seemed more useful since there are times, e.g. source code, e-mails, etc, where it's impossible without CSS |
| 20:02 | <yroc> | @Hixie, sorry |
| 20:02 | <Hixie> | tantek: file bugs |
| 20:02 | <Hixie> | s/etc/etc)/ |
| 20:02 | <tantek> | Am now of the opinion that the back-semantic definitions of <i>, <b>, <s>, <u> are nearly useless and confusing. |
| 20:02 | <Hixie> | wait forget my last regexp |
| 20:02 | <tantek> | Hixie, I'd expect you to close the bugs as "already discussed" |
| 20:02 | <Hixie> | tantek: not if there's new data :-) |
| 20:03 | <Hixie> | tantek: but if you want to get rid of <i>, make sure to say what element you'd use instead for its six zillion use cases |
| 20:03 | <tantek> | well, I don't really consider "changing my opinion" to be sufficiently new/objective "data" for that purpose. however, it's sufficiently anecdotally interesting IMO that I'm going to teach that way. |
| 20:03 | <Hixie> | tantek: same for the others (but not six zillion, more like 5, 3, and 2 respectively) |
| 20:03 | <tantek> | the point is not that there are no use-cases. the point is that the use-cases are not relevant enough to justify inclusion in the core language. |
| 20:04 | <Hixie> | yroc: see also http://wiki.whatwg.org/wiki/FAQ#Where.27s_the_harm_in_adding.E2.80.94 for rationale behind not adding features btw |
| 20:04 | <Hixie> | tantek: <i> has a ton of use cases that are pretty critical, imho. |
| 20:04 | <yroc> | @Hixie: will do |
| 20:05 | <tantek> | Hixie, that's a good link. |
| 20:05 | <Hixie> | tantek: the others i agree are weaker, and i wouldn't have added them if we didn't have a way to get them for free |
| 20:05 | <tantek> | Thanks, will be using that. |
| 20:05 | <tantek> | They're not free in terms of teaching cost. |
| 20:05 | <tantek> | <i> does stand out more than the others, I'll admit. |
| 20:05 | <tantek> | I have found more often uses for it in prose, posts etc. |
| 20:05 | <Hixie> | the teaching cost i think is gonna have to be paid for anyway |
| 20:06 | <tantek> | (per the "instance of a term" rough definition) |
| 20:06 | <tantek> | Hixie, nah, we can simply ignore old/obsolete elements when authoring. |
| 20:06 | <yroc> | I've interpreted <i>, for example, to be a "catch all" for semantic phrases that are conventionally marked up with italics. and |
| 20:06 | tantek | jokingly thinks of writing a summary of HTML: The Good Parts ;) |
| 20:06 | <Hixie> | there's so much material and software out there saying to use <b> and <u> and to a lesser extent <s> that you;ll have to field questions either way; we might as well, imho, head it off at the pass. |
| 20:07 | <Hixie> | by defining them |
| 20:07 | <tantek> | nah, easier to say, "old docs, ignore" |
| 20:07 | <Hixie> | since we have uses for them |
| 20:07 | <Ms2ger> | tantek, good luck finding those |
| 20:07 | <tantek> | just as we say for that-website-that-shall-not-be-named-but-shows-up-in-google-results |
| 20:07 | <tantek> | good luck finding what? |
| 20:07 | <tantek> | people love simplified summaries |
| 20:07 | <tantek> | that dispense with trivia, esoterica, obsolete "old people" stuff |
| 20:07 | <Ms2ger> | The good parts of HTML |
| 20:07 | <yroc> | You use <em> for stress emphasis, but you can't have tag for every possible case where italics are conventionally used. Therefore you defined <i> as a "catch-all". |
| 20:08 | <yroc> | @Hixie: is that a correct interpretation of <i>? |
| 20:08 | <Hixie> | tantek: "old docs, ignore" is not much cheaper than "b is for keywords, s is for intentionally inaccurate text (think price cuts), and u is for annotations (like spelling errors)" |
| 20:08 | <Hixie> | tantek: see http://www.whatwg.org/specs/web-apps/current-work/#usage-summary |
| 20:09 | <Hixie> | yroc: yeah, it's pretty close |
| 20:09 | <tantek> | Hixie, how is "keyword" different from "instance of a term"? |
| 20:09 | <Hixie> | yroc: (though i wouldn't use the word "italics") |
| 20:09 | <yroc> | @Hixie: why? and what word would you use? |
| 20:10 | <Hixie> | tantek: see the spec, it has some pretty good examples. the short answer is when you read text that has <i>, you use a different voice, whereas you don't read <b> differently at all, instead it's meant to draw your attention. |
| 20:10 | <Hixie> | tantek: e.g. gossip magazines will <b> a person's name so you can see the articles talks about them, but <i> wouldn't be appropriate for that. |
| 20:11 | <Hixie> | yroc: "instance of term" or "alternate mood or voice", like the spec :-) |
| 20:12 | <yroc> | @Hixie: right, but why are those particular (seemingly disparate) semantic elements lumped together in the first place? |
| 20:12 | <yroc> | Is it not because they are conventionally *italicized*? |
| 20:12 | <tantek> | Hixie, how do you "draw your attention" to <b> in a screen reader if "you don't read <b> differently at all" ? |
| 20:12 | <yroc> | in prose. |
| 20:13 | <yroc> | What does "instance of term", "alternate mood", and "ship name" have in common? |
| 20:13 | <yroc> | If not that they are conventionally italicized in prose? |
| 20:15 | <Hixie> | yroc: see the spec. The core definition is "alternate mood or voice", the others are all just examples of that. For example, when you say "I sailed on the /Enterprise/ for a couple of days", you tend to have a slight pause before the ship name and pronounce it with a slightly different stress. Same as "I like /felis domesticus/". |
| 20:15 | <Hixie> | tantek: a list or other UI, same as e.g. headings, tables, etc. |
| 20:16 | <yroc> | @Hixie not so sure about that one :-) |
| 20:17 | <yroc> | But you're the editor. I'm here to write what you're rationale is, so that's what I'll do. |
| 20:19 | <yroc> | Just circling back to <pre> for a moment, you said its continued inclusion is partially do to CSS being required. |
| 20:19 | <yroc> | Are you saying it's a goal of specing HTML to minimize authors having to use CSS? |
| 20:20 | <Hixie> | the core design of HTML is that it describes the page's structure/meaning/semantics/logic/content/other-buzz-words, while CSS describes the page's layout/presentational/formatting/style/other-buzz-words. The latter part is medium-specific and should never be necessary to understand the page. |
| 20:21 | <Hixie> | it should always be possible to just drop CSS entirely and still interact with / use / understand the page |
| 20:21 | <Hixie> | without CSS it'll likely be much uglier, but that's a separate issue |
| 20:22 | <yroc> | That's a good explanation -- makes me understand pre better, thanks. |
| 20:23 | <yroc> | In the spec, regarding links, it says: media, hreflang, and type attributes are "purely advisory", what exactly does that mean? |
| 20:23 | <yroc> | "Purely advisory", that is... |
| 20:23 | <Hixie> | "media" should be gone |
| 20:23 | <Hixie> | unless you mean <link> |
| 20:24 | <yroc> | It's a general link section... I think it includes <a> and <link> |
| 20:24 | <Hixie> | "purely advisory" means "just information, not something anyone is expecting you to take as fact or do anything interesting with, if you get more authoritative information, ignore the purely informative one" |
| 20:24 | <Hixie> | try reloading, i removed "media" a few days ago |
| 20:25 | <yroc> | K. |
| 20:28 | <yroc> | Another <pre> question (sorry!) Why are <br> elements allowed in pre? Doesn't that contradict the semantics? |
| 20:31 | <Hixie> | <br> in <pre> means nothing different than a newline |
| 20:33 | <yroc> | Yes, but isn't the whole point of pre, that the text is formatted "by typographic conventions rather than by elements"? (where I interpret <br> to be an element). |
| 20:33 | <Ms2ger> | Not really |
| 20:33 | <Ms2ger> | You can have <strong>s too |
| 20:33 | <Ms2ger> | Or whatever you like |
| 20:34 | <Hixie> | yroc: that's the intent, but it's harmless to allow <br> in practice |
| 20:34 | <Hixie> | yroc: in general we try to make things be invalid if that would help catch likely errors |
| 20:34 | <yroc> | Aha, got ya. |
| 20:34 | <Hixie> | yroc: but if something is just a bit silly, not really an error, and solving it wouldn't save anyone any time, then we allow it, typically |
| 20:35 | <yroc> | Or perhaps could you call it "non-conforming" |
| 20:35 | <Hixie> | yroc: see also http://www.whatwg.org/specs/web-apps/current-work/#conformance-requirements-for-authors |
| 20:35 | <Hixie> | and its subsections |
| 20:35 | <yroc> | I know I'm being very (too) analytical, but that's me! |
| 20:36 | <yroc> | Yes, I'll check it out. |
| 22:52 | <Hixie> | not sure how i feel about @whatwg tweeting out w3c bureaucracy :-P |
| 22:56 | <tantek> | unless WHATWG is planning a takeover from within of W3C bureaucracy... |
| 22:56 | <Hixie> | "takeover"? |
| 22:56 | <Hixie> | of what? |
| 22:57 | <Hixie> | we already write all the specs we want to write, what more is there to take over |
| 23:09 | <gavin> | the w3 brand |
| 23:09 | <zewt> | who would want that |
| 23:10 | <Hixie> | i'm certainly ok with them keeping that... |
| 23:10 | <zewt> | that'd be like buying out RealPlayer for the brand recognition |
| 23:10 | <Hixie> | hah |
| 23:11 | <gavin> | it's not valuable for their reputation amongst people who actually know what they do |
| 23:11 | <gavin> | it's valuable for all the other people in the world, of which we are but a small minority |
| 23:11 | <zewt> | nobody else cares |
| 23:12 | <gavin> | I wish that that that were true, but it's a horribly naive claim |
| 23:13 | <Hixie> | it's not clear to me what difference it makes. authors use what's implemented. the implementors are those "who actually know what they do". |
| 23:13 | <gavin> | plenty of people still think the w3 is highly relevant to web standardization |
| 23:13 | <gavin> | that reputation has value |
| 23:13 | <Hixie> | but what does their thinking that actually do, concretely? |
| 23:14 | <Hixie> | i mean, if it's just a matter of who gets credit, i don't care |
| 23:14 | <Hixie> | i'm happy for the mainstream media to pester the w3c PR team and let us get on with the work :-) |
| 23:14 | <zewt> | can't say i've ever known anyone who isn't actually implementing (or complaining about something not implementing) who cared at all about the w3c, or the ietf for that matter |
| 23:16 | <gavin> | it's not just about credit. reputation is an important part of being able to influence people and things. |
| 23:17 | <zewt> | and reputation is something the w3c has been losing rapidly of late |
| 23:20 | <Hixie> | gavin: what is it the w3c can influence that is valuable? |
| 23:20 | <Hixie> | we already write all the specs we want (or rather, hand the bandwidth) to write |
| 23:21 | <Hixie> | s/hand/have/ |
| 23:21 | <Hixie> | the browser vendors have influence on the spec |
| 23:21 | <Hixie> | the w3c has never had that influence |
| 23:21 | <gavin> | they can influence people's thoughts about what web standards are important |
| 23:22 | <gavin> | you might say that that's "not important" |
| 23:22 | <zewt> | i'd say that's a bit too vague to even have an opinion on, can you be more concrete |
| 23:22 | <Hixie> | do you have any examples of them doing that? |
| 23:22 | <Hixie> | i'm not sure what you mean |
| 23:23 | <Hixie> | like how they influenced people to think XHTML2, XForms, and RDF were important? |
| 23:24 | <zewt> | if browser vendors wants to implement something, authors want to use it and whatwg has the bandwidth to spec it, no amount of handwaving or ranting from the w3c would stop it from happening (if they even chose to try, which I'm not aware of them doing) |
| 23:25 | <Hixie> | well they tried to stop HTML |
| 23:25 | <gavin> | many people think that HTML5 CR is an important milestone, for example |
| 23:25 | <Hixie> | (and to a lesser extent canvas and microdata) |
| 23:25 | <gavin> | if the w3 tomorrow released a statement saying that HTML5 development hit a wall and that they'd need to delay its readiness as an official spec, many people would believe them |
| 23:26 | <Hixie> | and so? |
| 23:26 | <zewt> | meanwhile stuff would keep getting implemented and they'd look silly |
| 23:26 | <Hixie> | and people would still use it |
| 23:26 | <gavin> | no, people would not use it as much |
| 23:26 | <Hixie> | just like they have been using it for years while the w3c kept saying it wasn't done |
| 23:26 | <zewt> | that's quite a claim |
| 23:26 | <gavin> | I'm not talking about the existing uses. I'm talking about new uses. |
| 23:27 | <Hixie> | people have used new stuff that i've specced and people have implemented so quickly that we've actually been forced into compataibility constraints before i was done speccing them |
| 23:27 | <Hixie> | pushState() being the best example |
| 23:27 | <gavin> | getting people to buy that HTML is a suitable platform for mobile development is just as much about PR as it is about what gets implemented |
| 23:27 | <zewt> | not at all, it's only about getting apple and google to fix their crappy-to-useless mobile browsers |
| 23:28 | <Hixie> | getting people to buy that HTML is a suitable platform for mobile development is exclusively about whether HTML actually ir, or is not, a suitable platform. |
| 23:28 | <Hixie> | w3c has sod-all to do with that. |
| 23:28 | <Hixie> | (whatwg has very little to do with it either) |
| 23:28 | <gavin> | no, it's not at all exclusively about that |
| 23:28 | <gavin> | it would be nice if it were |
| 23:28 | <Hixie> | people are _trying_ to use the web, and can't because of browser limitations, and that has nothing to do with the w3c |
| 23:28 | <Hixie> | which would have them using XForms and RDF |
| 23:28 | <gavin> | but we don't live in a world where the only thing that matters is bits-shipped, nice as that would be |
| 23:29 | <gavin> | anyhow, I'm clearly not going to get anywhere arguing with you guys about this, so I'll drop it |
| 23:29 | <Hixie> | i think facebook's comments (which were based entirely on their experience, as far as i can tell, and not at all on the w3c) had more impact on people's view of the web as a platform for mobile dev than anything the w3c ever did or said |
| 23:29 | <zewt> | (and I suspect both apple and google half-ass their mobile browsers intentionally because they want people to write nonportable apps instead) |
| 23:30 | <gavin> | I gave a very theoretical example of something that the w3 could impact using its influence - they haven't done that, so it's kind of moot |
| 23:30 | <Hixie> | have they ever impacted anything with their influence? |
| 23:30 | <gavin> | I agree that they're losing their influence, obviously, but it's naive to claim that they don't have any |
| 23:31 | <gavin> | yes, plenty |
| 23:31 | <Hixie> | i'm happy to believe they have some if there's any evidence that they've had some, but so far the only impact i've seen is pretty much irrelevant. e.g. they had an impact on what doctypes people use, but that's just an opaque stirng. |
| 23:31 | <gavin> | companies have "must support w3 standards" on all of their checklists |
| 23:31 | <Hixie> | those companies write web pages that don't validate using flash and html5 features the w3c hasn't included in their specs. |
| 23:32 | <Hixie> | so i'm not sure that means anything. |