Re: [whatwg] several messages about the HTML syntax
On 03/02/2008 03:02 PM, Ian Hickson wrote: On Tue, 31 Jul 2007, Philip Taylor wrote: IE undocumentedly recognises some which nobody else does: aafsU+206D ACTIVATE ARABIC FORM SHAPING ass U+206B ACTIVATE SYMMETRIC SWAPPING iafsU+206C INHIBIT ARABIC FORM SHAPING iss U+206A INHIBIT SYMMETRIC SWAPPING lre U+202A LEFT-TO-RIGHT EMBEDDING lro U+202D LEFT-TO-RIGHT OVERRIDE nadsU+206E NATIONAL DIGIT SHAPES nodsU+206F NOMINAL DIGIT SHAPES pdf U+202C POP DIRECTIONAL FORMATTING rle U+202B RIGHT-TO-LEFT EMBEDDING rlo U+202E RIGHT-TO-LEFT OVERRIDE zwspU+200B ZERO WIDTH SPACE (I believe that list is complete.) The first eleven were suggested on https://listserv.heanet.ie/cgi-bin/wa?A2=ind9605L=html-wgP=4579 some time ago but don't seem to have gone very far (except into IE). I can see some legitimate users at http://www.tasb.com/services/field/staff/index.aspx?print=true and http://www.pelesoft.co.il/ and maybe there's a few dozen or hundred more elsewhere (but I can't measure it easily). There's some in text-art at http://yy28.60.kg/test/read.cgi/maido3/1096370177/l50 and quite a lot in weird places like http://cheese.2ch.net/life/kako/1010/10103/1010391447.html or http://zerosen52.gozaru.jp/log/1093422333.html that I don't understand but that seem to all be on 2channel (or copied from it). I've no idea how common they are in general. Are these used significantly on the web, or would they be considered highly useful if anyone knew they existed, or should HTML5 just ignore them? I'm very skeptical about introducing entities for the codes that are redundant with dir= and bdo (namely, lre, lro, pdf, rle, rlo). I agree 100% with this rationale. I don't know enough about the others to have an educated opinion. I can set up a search to examine the data in more detail. I don't know much about the others, but I can provide some info on ZWSP. It is (as specced) equivalent to wbr. Specifically, it * defines a word break (line-breaking opportunity) * thereby breaks Arabic joining For contrast: ZWSP - Breaks a word (and therefore also Arabic joining) with no visible space. ZWJ - Not a word break. Forces joining behavior. ZWNJ - Not a word break, but breaks joining. ZWJ and ZWNJ are primarily useful for Arabic and other shaped scripts. I'm not sure of the common uses for ZWJ, but ZWNJ is frequently used in Persian to visually separate grammatical prefixes from the rest of the word (without breaking the word or introducing extra space). ZWSP is more likely to be used in Thai and related scripts, to define word boundaries. Thai does not use spaces between words, so break opportunities need to either be marked with ZWSP or found with a dictionary. Even in the presence of automatic dictionary-breaking, however, there are ambiguous cases which will need ZWSP to show the correct break-point. There's further discussion about this in https://www.w3.org/Bugs/Public/show_bug.cgi?id=13108 I've no comment on concerns about compatibility with XML, but I can say that I've typed zwsp; multiple times expecting it to work and find it surprising that zwj; and zwnj; work, but zwsp; does not... ~fantasai
Re: [whatwg] several messages
On Thu, 18 Mar 2010, Simon Pieters wrote: On Thu, 18 Mar 2010 01:03:33 +0100, Ian Hickson i...@hixie.ch wrote: On Mon, 22 Feb 2010, Kornel Lesi�~Dski wrote: I'm wondering if data-* attributes should be renamed to priv-* to make it clearer that it's page's _private_ data. data- is such a nice generic prefix that I'm afraid sooner or later someone will start basing microformats-like markup on that. It's not a bad idea... Unfortunately data-* is already being used quite a lot and has been widely advertised, so we have to be careful with this. Anyone else have an opinion on this? I think we should keep data- as is. People have started to use it, we would waste their time by renaming it. On Thu, 18 Mar 2010, Henri Sivonen wrote: I don't feel strongly that either name is better. Though I would not that priv- doesn't make things much clearer since it's totally undefined who it's private to. Given that priv-* isn't clearly better, I think it would be better not to annoy early adopters of data-* with a name change. On Thu, 18 Mar 2010, Jonas Sicking wrote: Agreed. I haven't changed it. On Wed, 30 Jun 2010, Tab Atkins Jr. wrote: In the first paragraph of http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#embedding-custom-non-visible-data it says that a custom data attribute is an attribute in no namespace whose name starts with the string data-, has at least one character after the hyphen, Following this, div data-=foo would not put anything in .dataset. However, in the algorithm for getting the list of name-value pairs, it says to process each content attribute on the element whose first five characters are the string data- and whose remaining characters (if any) Following this, div data-=foo would make .dataset[]=foo. One of these references needs to be fixed, as webkit is implementing dataset right now. There's no contradiction here, it's just a difference between author conformance and implementation requirements in error conditions. Since WebKit implemented this as specced, I've left it unchanged: https://bugs.webkit.org/show_bug.cgi?id=41146 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages
On Thu, 18 Mar 2010, Alex Bishop wrote: In the processing model for image maps (section 4.8.13.2), step 8 of the processing instructions for area elements says that if the shape attribute is in the Circle state: Let x be the first number in coords, y be the second number, and r be the third number. The shape is a circle whose center is x CSS pixels from the left edge of the image and x CSS pixels from the top edge of the image, and whose radius is r pixels. Surely x CSS pixels from the top edge of the image should read y CSS pixels from the top edge of the image? On Thu, 18 Mar 2010, Ashley Sheridan wrote: I think the x here indicates an arbitrary number rather than units along the y-axis. On Fri, 19 Mar 2010, Tab Atkins Jr. wrote: No, the first sentence of the quote Alex gives makes it clear that x has a definite meaning, along with y and r. The spec has a typo - the distance from the top edge should indeed be y pixels, as that is the second number in the @coords attribute. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages
On Thu, Sep 3, 2009 at 7:41 AM, Ian Hicksoni...@hixie.ch wrote: On Mon, 31 Aug 2009, Jonas Sicking wrote: Upon further consideration I've renamed getStorageUpdates() to yieldForStorageUpdates(). 'yield' usually refers to halting execution. I would expect the above name to stop the current thread and allow other threads to run. While that is what could be happening here, I'm not sure that is the primary function of the call. It's more or less exactly what the method does, no? I think the common case is that no other thread is blocked, and we'll simply drop the lock on the storage mutex and continue execution of the current thread. Compare this to the Javascript 1.8 keyword 'yield', which always stops execution of the currently running code. Granted, Javascript 1.8 is Firefox only at this point, however I think the hope is that it'll get implemented across more browsers eventually. I really liked Darin's (?) suggestion of allowStorageUpdates as that seems to exactly describe the intended use of the function. We no longer prevent other page from updating the storage. allow implies a state change, which I don't think really matches what is happening here. (How do I disallow updates?) I don't understand why you associate allow with state change? It could just as well be allowing anything else. The word Updates is much more associated with state change i'd say. And that word occurs in your proposal too. Really it should probably be allowStorageAccess or yeildForStorageAccess to be more correct. / Jonas
Re: [whatwg] several messages
On Mon, 31 Aug 2009, Jonas Sicking wrote: Upon further consideration I've renamed getStorageUpdates() to yieldForStorageUpdates(). 'yield' usually refers to halting execution. I would expect the above name to stop the current thread and allow other threads to run. While that is what could be happening here, I'm not sure that is the primary function of the call. It's more or less exactly what the method does, no? I really liked Darin's (?) suggestion of allowStorageUpdates as that seems to exactly describe the intended use of the function. We no longer prevent other page from updating the storage. allow implies a state change, which I don't think really matches what is happening here. (How do I disallow updates?) On Mon, 31 Aug 2009, Mike Wilson wrote: Is there a preference for having the name indicate that we are finishing our own transaction, ie myStorageUpdatesAreNowComplete endStorageUpdates finishStorageUpdates commitStorageUpdates flushStorageUpdates saveStorageUpdates or should it indicate that others are now welcome to do their stuff, such as in: otherPagesStorageUpdatesAreNowWelcome allow(Other)StorageUpdates enable(Other)StorageUpdates ? I think we want more the second, but with shorter names. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages
On Tue, 7 Apr 2009, Jeff Creamer wrote: Hi. Since March of '06, Opera 9 has supported a custom extension to the canvas context called opera-2dgame. Importantly, their extension adds these methods: getPixel(x, y) Returns the pixel value (colour, opacity) at (x, y). Returned in the form #rrggbb if fully opaque and rgba(r, g, b, a) if it has some alpha transparency. setPixel (x, y, color) Allows you to set the colour of the pixel at (x, y). The third argument should be a CSS color - you could provide a string such as `red', a HTML colour code or even a rgba() value. I don't see any recent discussion of this. And I am also aware that the canvas drawing model is not pixel-oriented. Nonetheless, mightn't these functions be extremely useful? As the Opera folk point out, they bless game developers, and it occurs to me that they could be used for other neat, useful things, such as giving JavaScript a rudimentary RAM drive. Description including several demo programs and a discussion of security issues is available here. Why not make getPixel () and setPixel() a standard? On Tue, 7 Apr 2009, Oliver Hunt wrote: The ImageData APIs already provide the ability to do this and are already supported by Firefox, Opera and Safari. Given the ImageData APIs, and given that they are generally more efficient at the typical use cases for getPixel/setPixel, I haven't added getPixel/ setPixel to the spec. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages
The ImageData APIs already provide the ability to do this and are already supported by Firefox, Opera and Safari. Given the ImageData APIs, and given that they are generally more efficient at the typical use cases for getPixel/setPixel, I haven't added getPixel/ setPixel to the spec. Cheers, The opera-2dgame context also has APIs for collision detection and control painting http://my.opera.com/WebApplications/blog/show.dml/200788 I'm not familiar with the current canvas spec, but are these features supported somehow? Or would they have the potential to be included ?
Re: [whatwg] several messages
On Fri, 6 Mar 2009, Rikkert Koppes wrote: The example presented at the section element definition [1]. The given markup could be ok, however, with a look at the actual contents (a nice essay about apples), the h1 elements found in the section elements should actually be h2 elements, giving rise to the folowing document structure: Apples - Red Delicious - Granny Smith On Fri, 6 Mar 2009, Lachlan Hunt wrote: No, the example is correct. It's actually illustrating how you can use h1 elements in combination with the section elements to achieve the same structure. See the section on headings and sections and creating an outline for more info. I've added more explanatory text on the matter after that example. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages about figure and related subjects
On Mon, 25 Feb 2008, Maciej Stachowiak wrote:
On Feb 25, 2008, at 2:42 PM, Ian Hickson wrote:
label
This would preclude any sane way of putting form controls in
legends, which would be bad.
This can't be fixed in the spec.
Is the ability to put form controls in figure captions (let alone more
than one form control) really more important than ability to style them
sanely? Putting a form control in a figure caption seems unlikely to me.
Even more so for details, where form controls inside the label would
be confusingly inside another interactive element. Indeed, details is
arguably a kind of form control.
It's easy to imagine UIs, e.g. of templates, that have text boxes in
captions and are waiting for user input there. The default open file
dialog on Mac OS X has a kind of details-like UI with a control in the
caption, too. And finally, label already has so many semantics and
special rules and so forth that reusing it here just seems like a
particularly bad idea.
legend
Parsing issues in Firefox and IE:
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cscript%3Edocument.createElement(%27figure%27)%3C%2Fscript%3E%3Ctitle%3ETitle%3C%2Ftitle%3E%3Cp%3E...%3C%2Fp%3E%0A%3Cfieldset%3E%0A%20...%0A%20%3Cfigure%3E%0A%20%20%3Clegend%3Efigure%3C%2Flegend%3E%0A%20%20content%0A%20%3C%2Ffigure%3E%0A%20...%0A%3C%2Ffieldset%3E
...and the element doesn't appear in the DOM when there's no
fieldset in at least Safari and Firefox.
It seems to me that the problems with adding a new element are purely
aesthetic, while the problems with reusing 'legend' are practical and
harm deployment of the new element.
I don't think we should discount the problems with introducing a new
element quite that quickly.
I think our only option is to use legend, and, while in the
migration period, have people use markup like:
figure
legendspan class=legend ... /span/legend
...
/figure
...with styles like:
figure legend, figure .legend { ... }
Yuck. Surely writing legendspan class=legend ... /span/legend
is uglier than writing something like figcaption ... /figcaption.
Yes, but the former would only last a decade or two, while the latter
would last for the lifetime of HTML.
4) Another alternative would be using a new unknown element.
Whipping out my thesaurus, I see rubric, inscription. Another
possibility is something like figcaption (to avoid the problems
caption would cause for figures inside tables), but that wouldn't
be a good fit for details.
figcaption and detailscaption and so on just seems like it would
make the language really complicated.
But rubric is pretty reusable and about as semantically correct as
legend for general use as a caption:
http://dictionary.reference.com/browse/rubric
http://dictionary.reference.com/browse/legend
Except people don't know what a rubric is. They know what a legend is.
Legend is what people call this (or caption, but the parsing issues
there are even more intractable).
We've waited years for figure, can't we wait a few more while
browsers get their act together in their parsers?
figure could be used right now with CSS styling as backup and without
polluting up the markup if it didn't rely on an aspect of the HTML5
parsing algorithm that no browser implements yet. Otherwise we will
indeed have to wait years, needlessly.
I think the cost of a few years here is worth it. It's not like this is
input type=date where introducing this feature today is ten years too
late; the figure element is helpful, and worth adding, but not a
panacea. Thus I don't see the problems as a big deal.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages about ol, ul, dl, and related subjects
On Tue, 26 Feb 2008, Tab Atkins Jr. wrote:
- LH (caption for list! A must-have)
Why not using the title attribute?
Actually with figure the lh element is now better handled using
figure and legend.
Using figure and legend:
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cscript%3Edocument.createElement('figure')%3C%2Fscript%3E%3Ctitle%3ETitle%3C%2Ftitle%3E%3Cp%3E...%3C%2Fp%3E%0A%3Cfigure%3E%0A%20%20%3Clegend%3EList%20title%3C%2Flegend%3E%0A%20%20%3Cul%3E%0A%20%20%20%20%3Cli%3EList%20item%3C%2Fli%3E%0A%20%20%20%20%3Cli%3EList%20item%3C%2Fli%3E%0A%20%20%20%20%3Cli%3EList%20item%3C%2Fli%3E%0A%20%20%3C%2Ful%3E%0A%3C%2Ffigure%3E
While this isn't horrible, it isn't supported properly, as noted before. FF
currently just ignores the fact that there's a legend tag at all and
treats the list title as a plain text node. IE7 treats the legend as an
unknown tag and the title as a plain text node, even if you try to apply the
createElement shim.
Using lh:
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cscript%3Edocument.createElement('lh')%3C%2Fscript%3E%3Ctitle%3ETitle%3C%2Ftitle%3E%3Cp%3E...%3C%2Fp%3E%0A%20%20%3Cul%3E%0A%20%20%20%20%3Clh%3EList%20title%3C%2Flh%3E%0A%20%20%20%20%3Cli%3EList%20item%3C%2Fli%3E%0A%20%20%20%20%3Cli%3EList%20item%3C%2Fli%3E%0A%20%20%20%20%3Cli%3EList%20item%3C%2Fli%3E%0A%20%20%3C%2Ful%3E%0A
On the other hand, lh seems to be supported just fine in FF *and* IE7
(with the shim). This solution is usable *immediately*, which is a big
plus. Since we only want to allow a single header per list, though, I'd
prefer fully embracing the parallel with table and naming this element
lhead, thus implying it must come first and at most once.
It's true that legend has support problems, but these are fixable on the
long run (indeed the HTML parser requires that they be fixed, so either
this will eventually work, or we'll have to fix the parser and can revisit
this then). Adding a new element here is something I really want to avoid
because we already have half a dozen different ways to mark up titles,
captions, legends, labels, titles, and the like, and adding more just
seems silly.
At this point, though, why not just bend the definition of ul and ol and
allow hx tags directly? Both FF and IE7 form good DOM trees with this
markup.
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cscript%3Edocument.createElement('lhead')%3C%2Fscript%3E%3Ctitle%3ETitle%3C%2Ftitle%3E%3Cp%3E...%3C%2Fp%3E%0D%0A%20%20%3Cul%3E%0D%0A%20%20%20%20%3Ch1%3EList%20title%3C%2Fh1%3E%0D%0A%20%20%20%20%3Cli%3EList%20item%3C%2Fli%3E%0D%0A%20%20%20%20%3Cli%3EList%20item%3C%2Fli%3E%0D%0A%20%20%20%20%3Cli%3EList%20item%3C%2Fli%3E%0D%0A%20%20%3C%2Ful%3E%0D%0A
This solution doesn't seem to have a drawback, really. It's already
supported (*without* an IE shim), doesn't require the creation of a new
element, and is completely intuitive. Just specify (like thead) that it
must be at the start of the list, and can occur at most once.
This would address the problem for ol and ul, but wouldn't solve the
problem for all markup. The figure solution is more generic.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages about tables and related subjects
On Mon, 24 Mar 2008, Tab Atkins Jr. wrote: TH and TD * abbr (I think that's supported by screen readers, but need to verify) I don't really see that these attributes actually help anyone. I don't have a screen reader to verify, but afaik abbr= is used to provide a shortened form of the header when it is spoken aloud repeatedly. Leaving it out won't *hurt* anything, but the annoyance of hearing a large bit of header repeated over and over again when the table is complex enough to *need* a regular reminder would be enough, I think, for abbr= to be considered to help people. I use abbr= to this effect in my own tables. I understand the intent, but wouldn't it be better for the user agent to automatically abbreviate the table headers, for example by only saying the first few syllables of the first bit of unique text in the relevant headers once it has been said several times? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages about tables and related subjects
On Thu, 21 Aug 2008, Pawe�~B Stradomski wrote: I guess it's to difficult to implement such guessing right. thead tr th abbr=EuropeAmount sold in Europe/th th abbr=AsiaAmount sold in Asia/th th abbr=North AmericaAmount sold in North America/th .. /tr /thead This example would be fine, the UA could easily strip common leading text and just say Europe, Asia and North Am each time. (Stripping leading common text is a solved problem.) Another example (translated into English and simplified from real life Polish text): h1Camp details/h1 thead tr th/th th abbr=young scoutsCamp for young scouts (12-15 years old)/th th abbr=scouts leadersTraining camp for scout leaders (16-18 years old)/th .. /tr [...] In this example, the same algorithm would end up saying Camp for and Training as the two headers, but I think that's ok (if not necessarily ideal), since the user will know from having heard the full header several times that Camp for is short for the young people column and Training is short for the leaders column. Please don't remove this attribute, it doesn't hurt people who don't care about using it, but might make it more difficult for disabled people. Hearing same sentence over and over can kill usability. It's wrong to think that attributes that no-one use (and research indicates that this attribute really isn't used at all) don't cause harm. Every part of the language that we have increases the cognotive load of the entire language. A language with one feature is simpler to learn than a language with one feature and six unused features. I agree entirely that abbreviating long headers is something that should happen. But it should happen for _all_ tables, not just those written by conscientious authors. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages about tables and related subjects
The advantage of having an attribute referring to the current column of every table element is that it is easier to check that the right data are the right column. Columns are filled sequentially but the exact position in the sequence is accidental and meaningless in most cases. I tend to put the column keyword into the title attribute; this allows me to verify that the keywords are in the right order. This is verbose but it greatly improves source code readability. I think the abbr attribute could be used for this purpose as well (repeated on every cell). What do you think? Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Thursday, August 21, 2008 11:16 AM To: Tab Atkins Jr. Cc: whatwg List Subject: Re: [whatwg] several messages about tables and related subjects On Mon, 24 Mar 2008, Tab Atkins Jr. wrote: TH and TD * abbr (I think that's supported by screen readers, but need to verify) I don't really see that these attributes actually help anyone. I don't have a screen reader to verify, but afaik abbr= is used to provide a shortened form of the header when it is spoken aloud repeatedly. Leaving it out won't *hurt* anything, but the annoyance of hearing a large bit of header repeated over and over again when the table is complex enough to *need* a regular reminder would be enough, I think, for abbr= to be considered to help people. I use abbr= to this effect in my own tables. I understand the intent, but wouldn't it be better for the user agent to automatically abbreviate the table headers, for example by only saying the first few syllables of the first bit of unique text in the relevant headers once it has been said several times? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages
On Thu, 12 Jun 2008, Jorge Bay Gondra wrote: I was trying to imaging how it would be to build a site, and I realized that, in the case of site with 2 nav bars (typically 2 sidebars) there's not a way to specify which is the main sidebar and which is accessory... What do you think about specifying hierarchy for navs elements? On Fri, 13 Jun 2008, James Graham wrote: Arguably the outline algorithm already does this, since it places nav elements in a hierarchy along with other sections. For any case not covered by the outline algorithm I think that there would need to be some very strong use cases to add explicit markup here; what kind of UA features did you have in mind, and how well would they work if the markup was missing or incorrect on most pages? I agree with James here, what is the use case? On Thu, 12 Jun 2008, Jorge Bay Gondra wrote: Note: In the nav sample ( http://www.whatwg.org/specs/web-apps/current-work/multipage/the-root.html#the-nav) that includes several places with links, should be a good idea that the header and footer list of links have to be represented in an unordered list ul..., and not in a paragraph (!?), do you agree? Doesn't really matter either way. Do can do whatever you like. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages
On Tue, 20 Mar 2007, Nicholas Shanks wrote: I asked for the resurrection of HTML+'s imagefallback/image element last month. The reasons I cited were exactly the same as the reasons being given now in favour of the video element, however I was told (paraphrasing) Why bother, you can just use object and That would break existing implementations (though no such implementations were cited). So again, I ask for an image element to replace img. Benefits include: - As video would cater for video/* MIME types, image would cater for image/* I don't see how this is a benefit over img. - The alt and longdesc attributes can be part of the fallback content, allowing markup. If you need markup in the fallback, use object. (Or, better, consider exposing the content to everyone and not making it only available to those who don't see the image.) - You don't have to provide a type attribute and match on: object [type^=image/] Seems like img handles this too. On Wed, 21 Mar 2007, Nicholas Shanks wrote: On 21 Mar 2007, at 00:27, Simon Pieters wrote: The image start tag is parsed as if it were img, so you would get both the image and the fallback with HTML+ markup. Existing content rely on this behaviour, which is why it was added to the Parsing spec (see A start tag whose tag name is image, and see comment in source). So what's the problem? Content with a doctype of !DOCTYPE html or !DOCTYPE htmlplus is treated correctly, and content without a doctype is handled in quirks mode, where the UA can look for /image and if found in a suitable place, treat the start tag as image, or if not found, treat the start tag as img. Any content using image in strict mode with another HTML doctype is broken anyway, so it doesn't really matter how that looks. We're not doing any DOCTYPE-based parsing differences unless we _absolutely_ have to. This kind of switch is a giant source of implementation bugs and authoring problems. On Wed, 21 Mar 2007, Benjamin Hawkes-Lewis wrote: Or, how about getting more specific? bitmap [e.g. image/gif of an icon] diagram [e.g. image/svg of a map] photo [e.g. image/jpeg of a cat] Would that help search engines, I wonder? I don't see why it would (who would be making sure the right one was used each time?). This really doesn't seem to solve a real problem. On Wed, 21 Mar 2007, Anne van Kesteren wrote: I guess we have to agree to disagree here, but I think image src=fooDownload Foo 1.4brsmall(12 abbr title=MegabytesMBabbr)/small/image is preferable to img src=foo alt=Download Foo 1.4 (12 MB) which it would appear you prefer. Yeah. An abbreviation such as MB should be known by an accessibility client anyway and I think it's also perfectly capable of dealing with a few parenthesis. Besides, the latter has been standard practice for over a decade and trying to change authoring habbits with respect to that now seems silly. Besides, you can use object if you really care about proper fallback. In any case, what's the image in the case above? Why would you ever want that text _not_ visible when the image was visible? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages about URLs
On Tue, 13 Mar 2007, L. David Baron wrote: The wording of the value of href for base elements [1] is not quite the same as the wording for anchor elements [2], and technically [3] that wording allows only absolute URIs. They should probably both say they allow URI references (or IRI references), and the former should probably say be or equal rather than the rather vague contain. (I suspect there are similar problems elsewhere.) Or, if you don't like using the term URI reference everywhere (which may be worth avoiding), you should at least explain your usage in the Terminology section with reference to terms defined in the URI/IRI RFCs. I've done a huge rewrite of everything URL-related now which should resolve all these issues and make everything consistent and (hopefully) realistic. On Tue, 13 Mar 2007, L. David Baron wrote: http://www.whatwg.org/specs/web-apps/current-work/#terminology says: # For readability, the term URI is used to refer to both ASCII # URIs and Unicode IRIs, as those terms are defined by [RFC3986] # and [RFC3987] respectively. On the rare occasions where IRIs # are not allowed but ASCII URIs are, this is called out # explicitly. This is rather misleading, since backwards compatible use of URIs is not ASCII-only. While IRIs are a superset of conformant URIs, IRIs are a subset of real-world-URIs, since they have the encoding fixed to UTF-8. Backwards-compatible URI handling tries to send the same sequence of bytes that was in the document back to the server, percent-encoded byte-by-byte, by encoding the URI based on the encoding of the document. It's mildly more complicated than that, it seems, since path components always seem to use UTF-8 and query components use the doc encoding, but in any case, the spec now specified this. On Wed, 14 Mar 2007, Peter Karlsson wrote: Indeed. Considering the number of partly contradicting bug reports we have here at Opera on the issue, it would be nice to have it clearly spelled out, so that everyone is doing the same thing, and that we are doing what the user expects. Please let me know if the spec, as it stands, is acceptable. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages
The intended result of printing a document is that there is a printed copy of a reasonable quality available. The Web page can have no knowledge of that fact (unless it has feedback from the surveillance network, that is). Assuming that it is there after printing is wishful thinking. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Friday, June 06, 2008 2:12 AM To: [EMAIL PROTECTED] Subject: Re: [whatwg] several messages On Sun, 17 Jul 2005, Dean Edwards wrote: I'll add another case: the onafterprint event could be used in a wizard-style application where printing some document is step 3 of 10, for example. The application could proceed to the next step (not necessarily a different document) automatically without requiring a button that says click here when done printing. That's a case that a media-specific stylesheet cannot handle. Automating tasks and reducing clicks are both high priorities in my development of web applications. Good use case!
Re: [whatwg] several messages
On Sun, 17 Jul 2005, Dean Edwards wrote: Anne van Kesteren wrote: Shouldn't the print method on the window DOM interface be defined as well? Example: button onclick=window.print()print/button IE has some nice onbeforeprint/onafterprint events. Can we add these too? Defined both. On Mon, 18 Jul 2005, Olav Junker Kjær wrote: Arent these event mostly used to transform the view before printing it? I think this is better handled by a print-specific style-sheet today. There are some things for which CSS just doesn't work, sadly. On Tue, 19 Jul 2005, Greg Kilwein wrote: DG wrote: a) my invoice format requires a timestamp that says something like this: printed by [person] on [timestamp]. b) To capture the essence of the browsing session, I would like to build a breadcrumb at the bottom of the printed page, displaying titles and urls of pages the user have visited on the site during this visit. This is now possible. I'll add another case: the onafterprint event could be used in a wizard-style application where printing some document is step 3 of 10, for example. The application could proceed to the next step (not necessarily a different document) automatically without requiring a button that says click here when done printing. That's a case that a media-specific stylesheet cannot handle. Automating tasks and reducing clicks are both high priorities in my development of web applications. Good use case! If the ability to set printer settings such as portrait/landscape is available, an onbeforeprint event could be used to prompt the user whether they'd like to automatically switch their paper orientation to portrait or landscape before printing. (The same can be said for margins and headers/footers.) This can be done in the print dialog, but if it is truly important to how the page prints, a separate step that highlights the importance of the print setting to the user would be helpful in reducing calls to my company's tech support line. As specified, you could indeed use showModalDialog() for this. [snip other use cases] On Wed, 20 Jul 2005, Matthew Raymond wrote: Once again, I don't understand why you can't simply provide the user with a button on the web page that either calls up a printable version or clones the document so that the clone can be used for printing. (Granted, there probably isn't support for the latter, but it makes more sense to standardize that than to add onbeforeprint and onafterprint, especially when you consider the fact that a clone of the document can be held in memory for repeated printing or dumped.) I don't see why we shouldn't have both; after all, people are using onbeforeprint today, and it doesn't seem to have caused a disaster or anything. As far as I can tell, no part of WF2 or WA1 encourages malicious behavior on the part of the webmaster against the users. In fact, part of the problem I had with dataentry was that it could, in theory, be use in a hostile way towards legacy user agents. Therefore, I doubt this will ever make it into a WHATWG spec, especially when it can interfere with simple things like printing selected text, et cetera. This hasn't happened much, but certainly a user agent could disable scripts while it is printing. Now you've completely lost me, use-case-wise. On an intranet, why is a printable version of the document not an acceptable workaround? Well it's not as nice, is it. I mean, it's not the same experience really. Look at printing in Google Maps, for instance, where it brings up another page -- it's not as seamless as just printing the current page. Here's a question for you to chew on: What happens if you want to print and the webmaster screwed up something in the onbeforeprint or onafterprint event? Will it effectively disable printing? Will the document be restored once printing is finished? What if it's an AJAX application and the UI of the app is hidden for printing but never restored? This can all happen without printing too. On Wed, 20 Jul 2005, Matthew Raymond wrote: I think there's good enough reason to disallow a feature when you have the following: 1) The feature can be abused. 2) It alters the standard behavior of the browser. 3) It can be easily disabled with a modified open source browser or browser extension. ...or the browser can just allow it to be overriden. Point 3 basically counteracts the first two, imho. 4) Its use cases are partially covered by CSS. CSS is just as susceptible to 1 and 2, why isn't that a problem? 5) There are existing workarounds. Workarounds are just that. Not solutions. 6) An alternative has been proposed that has less potential for abuse, is more powerful, and doesn't change basic browser functionality. I don't see how it has less potential for abuse, really. I also am not sure it's really more powerful. On Wed, 20 Jul
Re: [whatwg] several messages about handling encodings in HTML
On Tue, 4 Mar 2008, �istein E. Andersen wrote: On Fri, 29 Feb 2008 01:21:20 + (UTC), Ian Hickson wrote: (I've made the characters not allowed in XML also not allowed in HTML, with the exception of some of the space characters which we need to have allowed for legacy reasons.) The C1 character U+0085 NEXT LINE (NEL) is also a Unicode space character, and this one is neither disallowed nor discouraged in XML as far as I can tell. I am not sure if we really want to support this character, though; Opera, Safari and Firefox do not seem to recognise it at all, and one IE7 installation seems to treat it as a non-breakable wide space, but this may well be font-dependent. (Allowing this character could be confusing given that #x85; does not refer to U+0085, but rather to an ellipsis for compatibility with Windows-1252.) I consciously excluded it. More importantly, the current draft seems to allow C0 (not only white space) controls and delete, as well as U+FDD0 to U+FDDF and the non-characters *FE and *FF when these are expressed as character references. Would it be possible to (dis)allow the same set of characters in both cases? Yeah, this was fixed yesterday. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages about cite
On Tue, 15 Apr 2008, Shannon wrote: All of them. class isn't intended for styling, it's intended to subclass elements. Regardless of the intention of the class element it is NOT used in the real world to subclass anything but styles and custom script. We may wish otherwise but that is irrelevant. The value of class to me is: * To get style information out of the content stream. * To allow the re-use and grouping of style information. * To provide alternate styles for printing, or user choice. * To identify related elements to javascript code. Sure, and that's fine -- so long as the subclassing is done in a way that isn't specific to the desired presentation, there's no clash with the intent of the attribute. In a perfect world, yes. In reality the people involved may not even work for the same company. I can see a situation arising where the meaning of classes are being assigned by a company like Google for use with their crawler but those classes are already be in use for presentation purposes. How will the crawler know which uses are intentional and which are not. How will the designer know which classes are reserved, when the system that will use them may not even exist yet. Ironically (given that you proposed using rel= instead) as far as I know Google has never based anything on class values, but has used rel= values (like rel=nofollow). As do I but that isn't relevant to the problem. If you feel that class should have a purpose other than it's widely used ones (styles and JS) then HTML5 must provide an alternative for these uses. I don't understand why you think it's an alternative use. All of these uses are subclassing the element, the styling and scripting is then hookd on those subclasses. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages about cite
Ironically (given that you proposed using rel= instead) as far as I know Google has never based anything on class values, but has used rel= values (like rel=nofollow). Which indicates to me that they were concerned enough about class=nofollow to not use it. I personally think that nofollow is not a (rel)ationship and probably a misuse of that element. Anyway I'm not fixed on rel, it could be any name as long as it isn't type or class. It could be argued that conceptually type, relationship and class are three words that all mean exactly the same thing (the relationship of an object to its environment) but we have them all now and all apparently serving different purposes. Adding another attribute like category=movie probably won't make things any easier. For that reason I believe rel= for categories that do something and class= for categories that need styles/js is enough of a distinction as it helps keep designers and developers out of each others way. As do I but that isn't relevant to the problem. If you feel that class should have a purpose other than it's widely used ones (styles and JS) then HTML5 must provide an alternative for these uses. I don't understand why you think it's an alternative use. All of these uses are subclassing the element, the styling and scripting is then hookd on those subclasses. It's alternative because it attempts to actually classify something rather than generically label it. I agree that class should only do the first and I do this with my own code but most designers do not. As far as the web design world is concerned class serves no purpose except as a JS/CSS hook. If you give class=book or class=movie special meaning or behaviour then you run the risk of clashing with existing stylesheets. Right now the mainstream web is misusing class. If you suddenly make class meaningful then some sites are going to get stung and not necessarily at any fault of their own - since the intellectual distinctions between labels and classes is of no concern to somebody putting pretty borders on a page. Shannon
Re: [whatwg] several messages about sarcasm proposals
Ian Hickson wrote: On Tue, 24 Apr 2007, Elliotte Harold wrote: It occurs to me that one of the most frequently used nits of pseudo-markup is to indicate sarcasm. For example, sarcasmYeah, George W. Bush has been such a great president./sarcasm Should we perhaps formalize this? Is there any benefit to be achieved by adding an explicit sarcasm element to HTML? [...] I do not believe that starting down this slippery slope will get us enough benefits to outweigh the costs involved. It isn't at all clear when we would have to stop (just look at the proposals above, which quickly went from just indicating sarcasm to pointing out other kinds of humour, other emotions, etc). I also believe that the rather limited success that analogous proposals have enjoyed in print typography over the years should be a warning sign for us to avoid introducing any explicit markup for this. As has been noted, class keywords can be used for this purpose on a site-by-site basis. I agree that sarcasm or joke or something equally specialized does not deserve its own tag. If there was a tag, it should be along the lines of double-meaning or not-literal or reader-beware which could then be classed as sarcasm or joke or possible insult. However, such element would probably go unused in any case. The only use case I can come up with is that a search engine could warn the user about the content in the search results. A search engine could also ignore content inside such element because a machine is not expected to understand the real meaning of such content and therefore it cannot be successfully indexed automatically. Content authors probably do not care about possible false positives of their content in the search engine query results. In cases where I've seen sarcasm or other such tags, they are meant to be seen by the reader as literal tags (that is, the letters sarcasm are part of the content, not markup). -- Mikko signature.asc Description: OpenPGP digital signature
Re: [whatwg] several messages about cite
On Tue, 15 Apr 2008, Shannon wrote: It's alternative because it attempts to actually classify something rather than generically label it. I agree that class should only do the first and I do this with my own code but most designers do not. As far as the web design world is concerned class serves no purpose except as a JS/CSS hook. If you give class=book or class=movie special meaning or behaviour then you run the risk of clashing with existing stylesheets. Right now the mainstream web is misusing class. If you suddenly make class meaningful then some sites are going to get stung and not necessarily at any fault of their own - since the intellectual distinctions between labels and classes is of no concern to somebody putting pretty borders on a page. We're not talking about making class meaningful. I'm not sure I understand what you are arguing against at this point. The proposal is just that authors should use class= to distinguish the various ways they use i so that they can (e.g.) style them differently. Where is the spec unclear? I should rewrite it to avoid any ambiguities. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages about cite
Ian Hickson wrote: We're not talking about making class meaningful. I'm not sure I understand what you are arguing against at this point. The proposal is just that authors should use class= to distinguish the various ways they use i so that they can (e.g.) style them differently. Where is the spec unclear? I should rewrite it to avoid any ambiguities. The spec is fine. I was referring to the discussion about adding a TYPE attribute for cite. Repeated below. Anne van Kesteren wrote: Ian Hickson wrote: Then would you want different markup for book titles, movie titles, play titles, song titles, etc? Or would you just expect the script to search IMDB for anything marked up with cite? Again, I don't really know. I could see a use case for a type attribute (as was suggested earlier in this thread), but that seems like a slippery slope. Suggestions? If we go with something like a TYPE attribute, I hope we can give it a better name. However, hiding semantics inside the value of an attribute is a poor markup design in humble opinion. (Although it also has some advantages.) It's subclassing: the general is sufficient, the specific better. Many markup languages use the design, and in this case, I think it's necessary. The class= attribute can handle this case. We appear to be talking about lookups, script, semantics and markup here rather than style; presumably to create custom link behaviours and assist in automated document processing. Perhaps there is an assumption that processing will only occur within the scope of the current page or site (and presumably therefore under the control of a single entity). However if cite were to have a type then it's likely that the first systems to take advantage of it would be search-engines and catalogues. I feel that class should not be suggested as an alternative to a type attribute because it is completely unreliable for this usage, for reasons I won't repeat. Using a type/rel/category attribute instead of class will assist in automated document processing and categorisation. It doesn't really matter whether a list of allowed types is defined or not since a search/directory crawler would probably deal with the uncommon or unsupported exceptions. But lumping the type of citation in with the class names used to style it is simply asking for trouble since it will also trigger any defined styles (probably unintentionally) and/or create nonsense categories like book_class in the processors' DB. I could imagine such a situation leading to the following catalogue output: This article contains: - 4 book citations - 2 book_class citations - 1 squiggly_underline citations Hope that makes my position on this clearer. If I misunderstood somebodies comments then I apologise. Shannon
Re: [whatwg] several messages about cite
On Wed, 16 Apr 2008, Shannon wrote: Ian Hickson wrote: We're not talking about making class meaningful. I'm not sure I understand what you are arguing against at this point. The proposal is just that authors should use class= to distinguish the various ways they use i so that they can (e.g.) style them differently. Where is the spec unclear? I should rewrite it to avoid any ambiguities. The spec is fine. Ah, ok. Well then good! It's subclassing: the general is sufficient, the specific better. Many markup languages use the design, and in this case, I think it's necessary. The class= attribute can handle this case. We appear to be talking about lookups, script, semantics and markup here rather than style; presumably to create custom link behaviours and assist in automated document processing. Perhaps there is an assumption that processing will only occur within the scope of the current page or site (and presumably therefore under the control of a single entity). Right. I don't think anyone is suggesting that we need to classify cite elements in a globally unique and unambiguous way -- what would be the use case for that? However if cite were to have a type then it's likely that the first systems to take advantage of it would be search-engines and catalogues. As someone who works for a search engine company, I highly doubt that. :-) Using a type/rel/category attribute instead of class will assist in automated document processing and categorisation. It doesn't really matter whether a list of allowed types is defined or not since a search/directory crawler would probably deal with the uncommon or unsupported exceptions. But lumping the type of citation in with the class names used to style it is simply asking for trouble since it will also trigger any defined styles (probably unintentionally) and/or create nonsense categories like book_class in the processors' DB. I could imagine such a situation leading to the following catalogue output: This article contains: - 4 book citations - 2 book_class citations - 1 squiggly_underline citations Hope that makes my position on this clearer. If I misunderstood somebodies comments then I apologise. I agree that class= won't work for this as a globally unique solution (short of a Microformat being developed for it). However, I don't think we need to find a globally unique solution, as the use cases for such a solution aren't especially compelling. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages about cite
I seemed to have missed these when going through the cite e-mails recently. On Sat, 16 Apr 2005, John Lewis wrote: A way to mark up titles is something I've always wanted in HTML. Currently, cite is only appropriate for actual citations. I rarely cite books, movies, etc.; I'm usually just talking about them. i is worse. It's basically meaningless. The best I can do is i class=movie or something, and even then it's only appropriate for titles that are italicized. Song names (and other minor works) are generally written in quotation marks, not italicized. i class=song is awful. cite has been extended to cover these cases now. On Sun, 17 Apr 2005, Matthew Thomas wrote: I think distinguishing between ordinary titles and real citations is untenable, because there's not a workable dividing line. Consider these examples: 1. pMy favorite book is citeThe reality dysfunction/cite by Peter F. Hamilton. It begins: qSpace outside the attack cruiser somethingBeezling/something tore open in five places./q/p 3. pMy favorite book is somethingelseThe reality dysfunction/somethingelse by Peter F. Hamilton./p Why should the title markup have suddenly changed? Do you expect the editor of an online magazine's book reviews department, for example, to have the presence of mind to change the title markup in the first paragraph of a review if she happens to excise the last quote from somewhere else in the review? I agree. The spec is aligned with this thinking as well now. On Sun, 17 Apr 2005, Anne van Kesteren wrote: I think that would be acceptable. Although I wonder if CITE would still be the right name... Can you still use CITE for persons in that case? pciteJohn E. Simpson/cite said in citeXPath and XPointer/cite: q.../q/p Per the current spec, you explicitly can't. On Sun, 17 Apr 2005, fantasai wrote: Anne van Kesteren wrote: Ian Hickson wrote: Then would you want different markup for book titles, movie titles, play titles, song titles, etc? Or would you just expect the script to search IMDB for anything marked up with cite? Again, I don't really know. I could see a use case for a type attribute (as was suggested earlier in this thread), but that seems like a slippery slope. Suggestions? If we go with something like a TYPE attribute, I hope we can give it a better name. However, hiding semantics inside the value of an attribute is a poor markup design in humble opinion. (Although it also has some advantages.) It's subclassing: the general is sufficient, the specific better. Many markup languages use the design, and in this case, I think it's necessary. The class= attribute can handle this case. On Sat, 7 May 2005, Henri Sivonen wrote: I'd define cite meaning a title of work (not a person and not limited to quoted works). The spec matches this now. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages about cite
If we go with something like a TYPE attribute, I hope we can give it a better name. However, hiding semantics inside the value of an attribute is a poor markup design in humble opinion. (Although it also has some advantages.) It's subclassing: the general is sufficient, the specific better. Many markup languages use the design, and in this case, I think it's necessary. The class= attribute can handle this case. I've seen a few suggestions now that class be used as an identifying attribute for purposes other than CSS. While this seems logical it raises some issues for designers and implementers. Consider the following: cite class=small book blueThe Neutronium Alchemist/cite In this example which of these classes is the type, and which serve only as style? A type or rel attribute is the better solution since it is generally understood to have a single value. book is an option but as others have pointed out it leads to potentially millions of new tags. There is also the issue to consider that website developers and website designers are usually a totally different species. Designers often have little understanding of how classes may be used in an application. The potential is high that the designer will use class=book on a totally unrelated element which is bound to cause visual problems if the application/developer is using the class as a program element. My proposed solution is to use the rel attribute which basically serves this purpose already. It also has less potential for conflicts than the type attribute since I have only ever seen rel used in the header whereas type has existing meaning for input fields and script tags. cite rel=book class=small blueThe Neutronium Alchemist/cite Shannon
Re: [whatwg] several messages about cite
On Tue, 15 Apr 2008, Shannon wrote:
I've seen a few suggestions now that class be used as an identifying
attribute for purposes other than CSS. While this seems logical it
raises some issues for designers and implementers. Consider the
following:
cite class=small book blueThe Neutronium Alchemist/cite
In this example which of these classes is the type, and which serve only
as style?
All of them. class isn't intended for styling, it's intended to subclass
elements. The subclassing can then be used for style, but using
presentational classes (that is, classes that describe the desired
presentation instead of the reason for that desire, the subclass of the
element) misses the point.
For example, saying class=blue with an associated .class { color: blue }
will quickly become confusing if you decide those things should be red. It
is in fact no better to use CSS that way than to use font color=blue.
There is also the issue to consider that website developers and
website designers are usually a totally different species. Designers
often have little understanding of how classes may be used in an
application. The potential is high that the designer will use
class=book on a totally unrelated element which is bound to cause
visual problems if the application/developer is using the class as a
program element.
All the people involved in the developement of a site and its style sheets
should of course agree on a set of class names.
My proposed solution is to use the rel attribute which basically serves
this purpose already. It also has less potential for conflicts than the
type attribute since I have only ever seen rel used in the header
whereas type has existing meaning for input fields and script tags.
cite rel=book class=small blueThe Neutronium Alchemist/cite
I strongly disagree with the characterisations of the class attribute in
this example.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages about cite
All of them. class isn't intended for styling, it's intended to subclass
elements.
Regardless of the intention of the class element it is NOT used in the
real world to subclass anything but styles and custom script. We may
wish otherwise but that is irrelevant. The value of class to me is:
* To get style information out of the content stream.
* To allow the re-use and grouping of style information.
* To provide alternate styles for printing, or user choice.
* To identify related elements to javascript code.
If class attribute was supposed to represent logical relationships or
groupings in the information/content then it has already failed.
The subclassing can then be used for style, but using
presentational classes (that is, classes that describe the desired
presentation instead of the reason for that desire, the subclass of the
element) misses the point.
For example, saying class=blue with an associated .class { color: blue }
will quickly become confusing if you decide those things should be red. It
is in fact no better to use CSS that way than to use font color=blue.
Agreed, I would personally never use class=blue. It was intended for
the example only so the distinction I was making between types and
styles was obvious. Designers are not used to thinking about these
things. They'll use whatever Dreamweaver offers them regardless of the
purpose for the information they are styling. Regardless of the
enlightened opinion here designers will continue to do what works
rather than what makes sense. You won't change that with a spec (that
most won't ever read). I've done a 2-year formal course in
computer-aided design and these things were just not taught.
All the people involved in the developement of a site and its style sheets
should of course agree on a set of class names.
In a perfect world, yes. In reality the people involved may not even
work for the same company. I can see a situation arising where the
meaning of classes are being assigned by a company like Google for use
with their crawler but those classes are already be in use for
presentation purposes. How will the crawler know which uses are
intentional and which are not. How will the designer know which classes
are reserved, when the system that will use them may not even exist yet.
I strongly disagree with the characterisations of the class attribute
in this example
As do I but that isn't relevant to the problem. If you feel that class
should have a purpose other than it's widely used ones (styles and JS)
then HTML5 must provide an alternative for these uses. I for one do not
intend to use inline styles at all as I prefer keeping the design
decisions outside of the HTML. That means you'll need to give me a list
of all meaningful classes that might be used with cite and other
elements - but of course nobody can.
On the other hand except for rel=stylesheet the rel attribute does not
have these encumbrances and so deserves consideration.
Shannon
Re: [whatwg] several messages about sarcasm proposals
On Tue, 24 Apr 2007, Elliotte Harold wrote: It occurs to me that one of the most frequently used nits of pseudo-markup is to indicate sarcasm. For example, sarcasmYeah, George W. Bush has been such a great president./sarcasm Should we perhaps formalize this? Is there any benefit to be achieved by adding an explicit sarcasm element to HTML? On Tue, 24 Apr 2007, Dan Brickley wrote: Seems rather culturally specific. I found from living in Boston for a while, that a British sense of humour often seems harsher and more sarcastic to our gentle US cousins. So I wouldn't burn this into an element name. On Tue, 24 Apr 2007, Charles Iliya Krempeaux wrote: An interesting proposal. Some other things to consider is some of the other ways people mark up sarcasm. Some people mark it with a winking smiley. As in... ;-) Or... ;) Although, this tends to be when a person is being sarcastic to be funny or to tease someone. I don't believe I've ever seen (or used myself) the winking smiley when I'm being sarcastic AND I'm trying to be mean to the person, to in a heated argument. (I.e., using sarcasm to make a point.) Also... I've heard that Ethiopian Semitic languages and French actually has a punctuation mark for sarcasm. On Tue, 24 Apr 2007, Alexey Feldgendler wrote: In Western typography, there is already a tradition to mark up irony with quotation marks: Yeah, George W. Bush has been such a “great” president. I don't think a structural markup is required for something that has a punctuation tradition, just like we don't introduce structural markup for sentences (the punctuation, such as a full stop after the sentence, suffices). There was such an idea, but it hasn't been widely adopted. http://en.wikipedia.org/wiki/Irony_mark On Tue, 24 Apr 2007, Benjamin Hawkes-Lewis wrote: Marking up emotions and tones is an interesting idea, especially when you consider the potential for talking browsers like Opera and Fire Vox. But the general utility of marking up sarcasm is somewhat broader than that for marking other emotions and tones, because sarcasm is /especially/ likely to be misinterpreted. Hence the popularity of the phrase: I was being sarcastic. The crux of misunderstanding here is that words are used in such a way as to undermine their surface meaning. You can undermine your own words more or less explicitly. On the one hand, you can give your audience no formal clues and depend entirely on common notions shared with audience (say, about the excellence of US presidents) for your disavowal to be detected, as with deadpan sarcasm and a lot of satire. Alternatively, you can rely on various conventions to modify the meaning of what is said, such as a nasal tone of voice, air quotes, and scare quotes. For this more explicit disavowal, TEI includes a fabulous soCalled element: http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-soCalled.html I suspect that the implicit and explicit variations reflect authorial intent and are not merely incidental. For that reason, I doubt markup would be appropriate for the implicit form. But markup could certainly be work well for the explicit variation. Talking browsers and screen readers offer a good justification for using markup in addition to punctuation for sarcasm. In Western languages at least, it is only through markup that can they clearly distinguish direct speech, quotation, and sarcasm, and assign them different voices. Quotation punctuation is far more fluid and ambiguous than other punctuation like commas, semicolons, question marks, full stops, and exclamation marks. So Alexey's analogy with how we treat more reliable punctuation is problematic. On Tue, 24 Apr 2007, Elliotte Harold wrote: There's an even stronger tradition to mark quotes with quotation marks, and yet we have the q element. On Tue, 24 Apr 2007, Brenton Strine wrote: So why not use the q element for irony as well, since a quote already indicates both quotations and irony. On Wed, 25 Apr 2007, Alexey Feldgendler wrote: For the same reason why we don't want i used to mark up emphasis, foreign words and defined terms (since italics are already used in typography for all of this). On Tue, 24 Apr 2007, Jon Barnett wrote: I think sarcasm is a good case for class extensions http://wiki.whatwg.org/wiki/ClassExtensions That could also apply to other tones of voice where context doesn't make it obvious, such as irony, anger, suspicion, elation, and veiled threats. On Tue, 24 Apr 2007, ddailey wrote: a. I rather like this sort of thing -- I wrote a note to the HTML WG a month or so ago (in reflection on the abbr acronym debate -- no I am not trying to reopen that) about a variety of allied issues: graphemic, pronunciation-related, and semantic http://lists.w3.org/Archives/Public/public-html/2007JanMar/0458.html . It may have not been
Re: [whatwg] several messages about noscript
On Sun, 14 Nov 2004, Anne van Kesteren wrote: I was wondering if the WHATWG is going to redefine how NOSCRIPT[1] works, since the current specification of it is quite difficult to implement. Besides, I don't think it ever was implemented properly. Also, brought to my attention by Bugzilla[2], how should content that isn't rendered be treated? [1]http://www.w3.org/TR/1999/REC-html401-19991224/interact/scripts.html#h-18.3.1 [2]https://bugzilla.mozilla.org/show_bug.cgi?id=242298 As far as I can tell, this is now all pretty much covered. If there are any specifics that I've missed, let me know. On Sun, 29 May 2005, Kornel Lesinski wrote: I see there is placeholder for noscript in WD, so here is my idea: Remove noscript element from specification. Since browsers support DHTML there is no need for specialized fallback element. Authors can use any element and hide/replace it using scripts. This is 100% backwards-compatible, works with all kinds of script types and allows partial fallback for partially working scripts. On Mon, 30 May 2005, Christian Biesinger wrote: That does not work if the user disabled javascript, or if the user agent does not support javascript (lynx, for example). On Sun, 29 May 2005, theharmonyguy wrote: And not just Lynx - there are plenty of handheld/phone browsers that are text-only or don't support all the latest features, including script. On Mon, 30 May 2005, Anne van Kesteren wrote: He's correct for a bit though. If you have the following element: div id=noscript pFoo bar, etc./p /div You could easily remove that DIV from the flow using javascript. And when javascript is disabled it would show up. Of course, compared to NOSCRIPT this is suboptimal at best. On Mon, 30 May 2005, Mikko Rantalainen wrote: I disagree. The noscript element is seldom used for anything else but this page requires javascript to work. The way I currently create web applications is to first make it work without any scripting and finally write scripts that tweak the final result. Often this tweaking requires removing existing elements or adding a few new ones but it's all doable in every browser I would script for anyway. The rest will get the default noscript version of the page. If the script is going to add or remove at least one element in any case there's very little extra work to remove the fallback behavior. If we remove the noscript element, the DOM tree will be simpler and therefore a little easier to script for the more complex cases. I'd prefer suggesting that the noscript version is the default case (and because it's the default there's no need for an extra element) and any features or behavior added with scripting is optional extra that needs to take care of everything required to make it work. On Mon, 30 May 2005, Henri Sivonen wrote: I disagree. noscript does not tell which script features a script needs. OTOH, the script itself can sniff for required DOM properties and proceed to remove the fallback if all the required properties are present. On Mon, 30 May 2005, Kornel Lesinski wrote: I don't see many real uses for noscript. Mostly because noscript is very primitive: * doesn't work when script-aware browser lacks neccessary DOM or XMLHTTPRequest support. * doesn't let you reuse its contents, so that's always wasted bandwidth (browsers don't put contents of noscript in DOM tree) * doesn't work with multiple script types Today most scripting solutions use progressive enchacement and don't need noscript at all. Decent dynamic menus work by transforming nested lists of links. Maintaince of noscript alternative would be wasted effort. sFIR and flashObject degrade nicely without noscript. Actually you don't have to look far - entire WebApps specification is designed this way! I've left noscript conforming in text/html, because while it's true that it isn't overly useful these days, it's not especially _harmful_ either, and we have to support it anyway, so removing it doesn't gain us much. Removing it _would_, however, introduce spurious and annoying conformance error messages in legacy content updated to use HTML5 features. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages about quotations
Ian Hickson wrote: Summary: I've made the spec require that any punctuation for q be included inside the element; I've added examples for q. ... How would you define CSS pseudo-elements for open and close quotes in such a way that they would be implementable and would not match apostrophes and would correctly differentiate between open and close quotes in languages that use the same character for opening and closing and in languages that invert the direction of guillemets compared to French? I would introduce two pseudo-elements, ::quote-start and ::quote-end, which match one or more characters with the Quotation_Mark property (as per Unicode PropList) found at the start or end of an element, if such text is a direct child of the element (skipping White_Space characters). I've started this idea down the path of the CSS working group. Please send a message with your proposal to www-style for discussion and CC www-international. (We use the wiki to track issues, not as a substitute for mailing list discussion. Also, it would be important to have i18n people involved since punctuation styles vary across languages and I'm not sure Unicode's Quotation_Mark property is adequate.) ~fantasai
Re: [whatwg] several messages about quotations
Summary: I've made the spec require that any punctuation for q be included inside the element; I've added examples for q. On Wed, 10 Nov 2004, Thomas Scholz wrote: Ian Hickson schrieb: I sometimes want to take quotes and put them into floats with huge oversized quotemarks under the text at the top right and bottom left (it's quite a common effect in glossy magazines). This can't be done unless you can address the quotes directly somehow. What about an element quote? Well, we have an element (q), the problem is what to do with the quotation marks. On Wed, 10 Nov 2004, Henri Sivonen wrote: On Nov 10, 2004, at 03:34, Ian Hickson wrote: I agree with Henri, this is an authoring problem, not a styling a problem. But Henri agreed with me, saying that using markup for this was a bad idea. What I agreed to was that using markup for smartening ASCII quotes was a bad idea. I wouldn't mind using spans for the special case of floating the quotation marks. How would you define CSS pseudo-elements for open and close quotes in such a way that they would be implementable and would not match apostrophes and would correctly differentiate between open and close quotes in languages that use the same character for opening and closing and in languages that invert the direction of guillemets compared to French? I would introduce two pseudo-elements, ::quote-start and ::quote-end, which match one or more characters with the Quotation_Mark property (as per Unicode PropList) found at the start or end of an element, if such text is a direct child of the element (skipping White_Space characters). I've started this idea down the path of the CSS working group. On Wed, 10 Nov 2004, Max Romantschuk wrote: I thought the issue on the table was the fact that the spec defines the following: Visual user agents must ensure that the content of the Q element is rendered with delimiting quotation marks. The problem arises with UAs which don't understand q, and leaves out the quotation marks. This results in the loss of the information that the element content was a quote. On Wed, 10 Nov 2004, Thomas Scholz wrote: No, some UAs insert quotes, some don't. A new defined element quote shouldn't require automagic quotes and leave this up to the author. On Wed, 10 Nov 2004, Max Romantschuk wrote: OK. I see your point. Even though this would esentially solve the problem I would be hesitant to support such a solution. If two elements mean the same thing on a semantic level and only differ in presentation we're essentially returning to the HTML3 model of mixing content and presentation. I'm not claiming I have a better solution, but I feel we strive to separate content from presentation and keep the semantic model as unambiguous as possible. I agree that introducing a new element just to solve the problem isn't really a good solution. On Sat, 16 Apr 2005, fantasai wrote: John Lewis wrote: I strongly believe quotation marks (for songs, etc.) should be written by the author in the document, not added with CSS. q is messy and hard to use. I agree that q has problems, particularly with en-US style punctuation. However, if the italics is going to be in the CSS, I think the quotation marks should also be there. I'd like to note also that citations in languages other than English -- in Chinese, for example -- are probably done differently. (This is why either all citation formatting should be the responsibility of the author or none of it should be.) I agree that the CSS should be able to override quotation punctuation. On Wed, 13 Jul 2005, Bjoern Hoehrmann wrote: What is proposed for XHTML 2.0 does not really work, I've discussed this in http://lists.w3.org/Archives/Public/www-html/2004Aug/0011. Would it work if we required all punctuation to be included in the source (inside the q element), and provided the above-suggested pseudo-elements to deal with styling? Did you ever receive a reply to that e-mail? On Tue, 3 Apr 2007, Asbj�rn Ulsberg wrote: On Mon, 02 Apr 2007 23:52:48 +0200, Ian Hickson [EMAIL PROTECTED] wrote: Instead of enhancing the Q element, we should deprecate it and replace it. Replace it with what? A new element, quote for example. What should we do with the existing content that uses q? It will still be supported, but deprecated in favour of quote. This has been an open issue in the WHATWG for a while but nobody has come up with a particularily compelling solution -- either the solutions drop compatibility with existing content, or existing UAs, or require complex CSS features. (My own proposal falls in the latter camp; it makes q require quote marks around q elements (author-provided), then provides complex CSS that can select those quotes for replacement -- for legacy unquoted content you get the quotes added by CSS, for everything else you
Re: [whatwg] several messages relating to the alt= attribute
The HTMLWG's ISSUE-31 is Should img without alt ever be conforming. It isn't clear from this issue what exactly the problem with the current spec text is. The current text in the spec requires alt= in all cases except when the page is generated in a manner where alternative text is not available, or when there is no possible way to provide text that is in any way a replacement for the image. Two examples are given, namely a photo upload site, and a Rorschach inkblot test. In the former case, the image is generated automatically and the program simply does not have enough information to provide alternative text. In the latter case, _any_ description would miss the point of the test (which is to see what descriptions people come up with). The spec contains very strong wording requiring alternative text in all manner of possible situations, and encouraging it even in the aforementioned cases. I'm not sure what else we can do short of just making it non-conforming to create bulk-upload image hosting sites or write documents that contain inkblot tests. If the issue's title is ever to be answered in the negative, it would be helpful for solutions to the two examples above to be provided. I've closed the issue, to indicate that I have examined it in detail and come to a tentative conclusion. Further input from anyone, but in particular the PFWG, is welcome and encouraged; if anyone disagrees with this issue they are of course encouraged to reopen the issue in the issue database, preferably at the same time as providing further information to help answer the issues given above. :-) Here are some answers to other issues raised on the topic: On Thu, 6 Jan 2005, James Graham wrote: Matthew Thomas wrote: For perhaps 95 percent of the images on the Web, the most appropriate alternate text is nothing at all. (In 2003 I did a survey of images in Wikipedia articles, where images aren't even used for decoration, and still found that alt= would be the most sensible choice for 77 percent of them.) So for that 95 percent, assuming that no alt is alt= would improve the user experience. Unfortunately, the other 5 percent would ruin the idea. When screenreaders are wading through inaccessibly-written pages, sometimes images are used for navigation (graphical menus, for example), so the user needs an indication that an image is there (whereupon they can guess its function by its URI). Assuming that all these images had alt= would make such pages completely unnavigable. Both this and the other point that Jim made (implied alt is hard to debug) strongly suggest that alt should be optional, not implied. The lack of an alt attribute would legitimize any inference about suitable alternative text that the web browser wanted to perform. Therefore it would remain best practice to explicitly declare alt= where the image is purely decorative. I expect many web developers would favor this approach since the validator complaining about a lack of alt= has been perceived as unnecessary nannying and so the requirement has widely been ignored. Making alt optional probably wouldn't damage accessibility as much as might be thought because a) bad alt text is at least as bad as missing alt text and b) there exist other tools that explicitly check documents for accessibility which could flag missing alt attributes. This is the reasoning behind the current wording of the specification. On Thu, 6 Jan 2005, Andrew Kirkpatrick wrote: Alt should be required on inputs of type=image, area elements, and perhaps on images within anchors (although images within an anchor that also contains text or another image with alt could be fine without alt also, so I'm not sure how to best handle that). The form control issues (input type=image) are pending a result from the forms task force (I don't want to write that part of the spec only to find the whole thing has to be rewritten). Omitted alt= attributes only make sense (and are only, reluctantly, allowed) when the site serving the image simply has no idea what the image is, but knows that it is important. One could easily imagine a situation where that is the case, but where the image is in a link. For example, any image on Flickr that doesn't have useful metadata falls into this category. Thus I don't think we can make that requirement, as it would only lead to nonsense alt text or the concept of validity being ignored altogether. As a person who works in the area of accessibility, I'm inclined to agree that alt doesn't really need to be required. What is unusual is that not only is this a solid idea theoretically, but the user agent base supports it already. That's good to know. Users can, and probably would continue to be able to, get their user agent to voice all images without regard to the presence of alt if they wanted. Having alt be required is an argument that assumes that
Re: [whatwg] several messages
Ian Hickson (2008-03-23): On Tue, 18 Mar 2008, Christoph Päper wrote: a spanvalid non-negative integer/span greater than zero. Isn't that the description of a valid positive integer? If that term is not used or defined yet, why not? Because positive is confusing to people. Some people (including me) think that 0 is positive. Sure, but I thought non-negative integer was used to make it clear that zero was included. Thus for the (fewer) instances like this one, where zero is excluded, positive integer becomes available. You only need to say this once in 3.2.3., which is linked each time any way, and thereby improve readability. You could of course adopt the other definition of 'positive' instead. Btw., there is a typo in the first sentence of 3.2.3.1.: the second 'of' should be an 'or'. Comparison of character string length: Zero Count -oo .. +oo integer ind.7 i -oo .. -1negative integer ind. 16 -i non-positive integer less than zero sep. 35! +i0 non-positive integer pos. 20!+i -oo .. 0negative integer or zero ind. 24 -i|0 non-positive integer sep. 20!+i non-positive integer or zero pos. 28! +i|0 0 .. +oo non-negative integer ind. 20!-i positive integer or zero sep. 24 +i|0 positive integer pos. 16 +i 1 .. +oo non-negative integer greater than zero ind. 38!- i0 positive integer sep. 16 +i positive integer greater than zero pos.* 34 +i0 pos.: zero is positive sep.: zero has a separate state ind.: independent of choice (based on negative never includes zero) The second and third case (only negative integers) are virtually unneeded in HTML5. ind. sep. pos. 0 20 24 16 1 38 16 34 ø 29 20 25 On average character count supports non-positive zero (especially if combined with ind. wording), but if zero is usually included in HTML5, it may make sense to use positive in that way. The fully independent wording currently chosen is the worst alternative (by this criterion). So either non-negative integer / positive integer (instead of positive integer or zero / positive integer) or positive integer / positive integer greater than zero, but neither non-negative integer / non-negative integer greater than zero nor non-negative integer / positive integer greater than zero. One may consider these independet formulations, too: -oo .. -1integer less than zero ind. 22 i0 -oo .. 0integer less than oneind. 21 i1 1 .. +oo integer greater than zeroind. 25 i0 .oO(Much fuzz about nothing.) Why can |rowspan|, unlike |colspan|, be 0, but is then also normalised to 1? It's not normalised to 1, is it? I don't understand. It is not, I misinterpreted this sentence: Its default value, which must be used if parsing the attribute as a non-negative integer returns an error, is also 1.
Re: [whatwg] several messages about tables and related subjects
Dnia 23-03-2008, N o godzinie 19:29 +, Ian Hickson pisze:
Executive summary:
* header/id is in.
* summary= is not in.
* axis= is not in.
* the automatic header association algorithm has been expanded.
* a number of minor fixes and editorial edits were made.
For details, see revisions r1373 to r1396.
On Thu, 16 Aug 2007, Ben Boyle wrote:
Look at the balance sheet (3rd table). It's like we have nested sections
within the table. There's net assets that's broken down into current
assets, non-current assets and liabilities, each either their own
heading and totals (footer).
It would be interesting to investigate table markup that could support
complex relationships within tables like this. It may be a bit esoteric,
and can probably be handled through classes for those that need it. In
either case it's very important we can clearly associate the headers
with the right cells. I think it would be useful to be able to identity
the totals (footers?) in each section too.
For simple cases like:
WATER FOOD
CATS
male 871 12
female900 10
TOTALS FOR CATS1771 22
DOGS
male 871 12
female900 10
TOTALS FOR DOGS1771 22
TOTALS 3542 44
...you can now easily get this effect by putting everything in the left
hand column into ths, everything on the top row into ths, and
everything on the bottom row into its own tfoot.
Does that work?
You are trying to map a cube onto a plane here.
It will never work,
except for the simplest cases the reader can easily imagine.
More formally, your table has two independent attributes enumerated:
table(species of {cats, dogs, all}, sex of {male, female, total})
and two dependent numerical ones:
= (water, food)
and should have the following four columns:
species sex water food
An alternative would be to use tabs
to present slices of the cube for different animals
--- but it is out of scope here, I presume.
I'm going to through a crazy idea into the mix and suggest that
section, header and footer may be useful within data tables for
this very purpose.
I'm not clear on how that would work. (Especially considering backwards
compatibility and the CSS table model.)
Aren't the two answers below contradictory?
On Tue, 14 Nov 2006, Simon Pieters wrote:
Currently tbody requires at least one tr element. [1] Why not zero
or more? I think tr is for tbody like li is for ul/ol (or a
dtdd group is for dl).
Because if you have zero tr elements, you actually have zero tbody
elements, which is allowed.
On Thu, 5 Apr 2007, Simon Pieters wrote:
Why does tbody require one or more tr elements, as opposed to zero
or more?
Fixed.
Cheers,
Chris
Re: [whatwg] several messages about tables and related subjects
TH and TD * abbr (I think that's supported by screen readers, but need to verify) I don't really see that these attributes actually help anyone. I don't have a screen reader to verify, but afaik abbr= is used to provide a shortened form of the header when it is spoken aloud repeatedly. Leaving it out won't *hurt* anything, but the annoyance of hearing a large bit of header repeated over and over again when the table is complex enough to *need* a regular reminder would be enough, I think, for abbr= to be considered to help people. I use abbr= to this effect in my own tables. ~TJ
Re: [whatwg] several messages
On Tue, 18 Mar 2008, Christoph P�per wrote: + h4Attributes common to codetd/code and codeth/code elements/h4 + pThe codetd/code and codeth/code elements may have a dfn + title=attr-tdth-colspancodecolspan/code/dfn content + attribute specified, whose value must be a spanvalid non-negative + integer/span greater than zero. Isn't that the description of a valid positive integer? If that term is not used or defined yet, why not? Because positive is confusing to people. Some people (including me) think that 0 is positive. + pThe codetd/code and codeth/code elements may also have a + dfn title=attr-tdth-rowspancoderowspan/code/dfn content + attribute specified, whose value must be a spanvalid non-negative + integer/span. Why can |rowspan|, unlike |colspan|, be 0, but is then also normalised to 1? It's not normalised to 1, is it? I don't understand. On Wed, 19 Mar 2008, Michael Enright wrote: On Tue, Mar 18, 2008 at 2:23 PM, Christoph P�per [EMAIL PROTECTED] wrote: + h4Attributes common to codetd/code and codeth/code elements/h4 + pThe codetd/code and codeth/code elements may have a dfn + title=attr-tdth-colspancodecolspan/code/dfn content + attribute specified, whose value must be a spanvalid non-negative + integer/span greater than zero. Isn't that the description of a valid positive integer? If that term is not used or defined yet, why not? The mathematical definitions of positive and negative integers exclude zero, but the less-expert reader might not realize that zero is not valid for colspan unless it is made explicit. integer greater than zero would be one way to say it. Otherwise positive non-zero integer? I think the current text is fine. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages
On 23/03/2008, Ian Hickson [EMAIL PROTECTED] wrote: Isn't that the description of a valid positive integer? If that term is not used or defined yet, why not? Because positive is confusing to people. Some people (including me) think that 0 is positive. I'm fairly sure that there are also some people out there who argue that you can have both -0 and +0, and these are two different numbers. Paul -- Paul Waring http://www.pwaring.com
Re: [whatwg] several messages
On Sun, 23 Mar 2008, Paul Waring wrote: On 23/03/2008, Ian Hickson [EMAIL PROTECTED] wrote: Isn't that the description of a valid positive integer? If that term is not used or defined yet, why not? Because positive is confusing to people. Some people (including me) think that 0 is positive. I'm fairly sure that there are also some people out there who argue that you can have both -0 and +0, and these are two different numbers. Sure, my point is just that we should avoid such confusion in the spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages about the HTML syntax
Dnia 03-03-2008, Pn o godzinie 20:18 +, David Gerard pisze: On 03/03/2008, Ian Hickson [EMAIL PROTECTED] wrote: On Mon, 3 Mar 2008, Krzysztof Żelechowski wrote: When I want to define a paragraph-style tool-tip, I am left with the following choice: either make the source code unreadable by making an excessively long line (this is also true for URI attributes but they are not expected to be readable) or make the tool-tip ugly by inserting line breaks. (It cannot be done in an portable way because the width of the tool-tip window and the fount metrics at the viewer's UI are unknown). I recommend not making paragraph-long tooltips. That's terrible user interface. But how will we read the asides on xkcd.com ?! Admittedly, we cannot, at least not in Firefox. Hm. Chris
Re: [whatwg] several messages about the tree construction stage of HTML parsing
Executive summary: Hoo boy did these e-mails end up with a lot of complicated changes -- a total of 38 different checkins. Some were editorial, but others were quite invasive changes. Here are the main ones: * Merged insertion modes and phases. Theoretically this didn't change anything but as I'm sure I broke many things, please let me know what I should fix. Note that I did the changes in steps, to make reviewing the changes easier. (r1308-r1313) * Make a text node before an html start tag be a parse error. (r1314) * Strip spaces between html and head tags. (r1332) * Make title not get moved to head. (r1328) * Fix the processing of /form to work like /div. (r1320) * Make listing parse like pre in terms of leading newlines. (r1330) * Make spaces in table get reparented if there's been other content that got reparented. (r1326) * Make input type=hidden in table not get reparented unless something else has been reparented. (r1331) * Make style and script in table not get reparented. (r1335) * Make select inside table get handled compatibly. (r1342) * Fix bugs with the AAA algorithm in tables. (r1343) For the full list see the diffs from r1308 to r1346. On Thu, 19 Jan 2006, Simon Pieters wrote: I did some more testing[1] on this. It seems that in Mozilla and Opera, the DOM tree for... tabletbodyformtrtdinput/td/tr/form/tbody/table ...looks like this: TABLE - TBODY - - FORM - - TR - - - TD - - - - INPUT In IE6 the DOM tree looks like this: TABLE - TBODY - - FORM - - - TR - - - - TD - - - - - INPUT Even though the FORM is not an ancestor to the INPUT in the DOM tree in Mozilla or Opera, the DOM2 HTML attributes .form and .elements work as if it was. The same holds true when form is placed as a child of TABLE, TBODY (presumably also THEAD and TFOOT), and TR. [1] http://zcorpan.1go.dk/test/html/table-form/ The problem with IE's tree is that it is incompatible with the CSS tabel model. The problem with the Mozilla and Opera tree is that the form is still in the way, but since it's not an ancestor, it doesn't really have to be there at all. Hence the HTML5 processing. On Fri, 29 Jun 2007, Henri Sivonen wrote: If the spec dealt with the html start tag token directly in the root element phase, the parse error in the main phase wouldn't need to be conditional. (Implementations that experience a perf benefit from not mutating the attributes of a node probably want to hoist the html node creation to the root element phase for perf reasons, too.) Done. On Mon, 11 Feb 2008, Philip Taylor wrote: There's also an issue with: !doctype html foo html not producing any parse error, because the html is the first start tag token (at least under my interpretation) and therefore is considered valid. Handling html specially in the root element phase seems like a reasonable way of fixing this. Fixed. On Sat, 30 Jun 2007, Henri Sivonen wrote: Under before head the case 'A start tag token whose tag name is one of: base, link, meta, script, style, title' is the same as any other start tag token. Removed. On Sun, 1 Jul 2007, Henri Sivonen wrote: In the tree construction part of the parsing algorithm, void elements that are generally supposed to be children of the head element never get popped. (Void elements that are generally supposed to be descendants of the body element are appropriately popped immediately.) Fixed. (Assuming this only affected meta, base, and link while in head, anyway.) On Sun, 1 Jul 2007, Henri Sivonen wrote: Please add a note that says that the context concept of the [R]CDATA algorithm causes title to be moved to head here. No longer applicable (title is no longer reparented). On Sun, 1 Jul 2007, Henri Sivonen wrote: In the tree construction part of the parsing algorithm, the rationale for formulating the generic [R]CDATA parsing algorithm the way it is formulated is not given. The formulation is unusual compared to the rest of the chapter, so it is reasonable to expect that there's a specific reason why it is written the way it is written. It was written the way that my mind thought about it... My practical concern is this: In my implementation the tokenizer owns the main processing loop. Therefore, the tree builder can only change its state on a per-token basis and cannot pull another token in response to processing one token. (Instead, it can set its own flags, return control to the tokenizer and wait for the tokenizer to call back into the tree builder again.) I have solved the problem as follows: cdataOrRcdataTimesToPop is initialized to 0. When the spec invokes the generic [R]CDATA parsing algorithm, instead of running it, do the following: 1. If the context node is the current node, 1a. Create an element for the token. 1b. Push the element. 1c. Set the content model flag of the tokenizer. 1d. Set
Re: [whatwg] several messages about the HTML syntax
Dnia 02-03-2008, N o godzinie 23:02 +, Ian Hickson pisze: On Tue, 31 Jul 2007, Simon Pieters wrote: Aha. I didn't think of testing attributes. Safari preserves CRs in attribute values, both real and NCRs. CRLF pairs, LFCR pairs, CRs and LFs cause a single linebreak in the tooltip. In data, CRs don't cause linebreaks. For title=, IE preserves CRs in attribute values, both real and NCRs. CRLF pairs, CRs and LFs in the DOM gets rendered as a signle linebreak in the tooltip. For value=, all types of linebreaks are converted to CRLF pairs. In data, only CRs cause linebreaks and LFs are rendered as spaces. Firefox preserves CRs in attribute values, both real and NCRs. CRs are ignored and LFs are rendered as spaces in the tooltip. In data, CRs don't cause linebreaks. For title=, Opera drops LFs in attribute values, both real and NCRs, and converts CRs (both real and NCRs) to spaces. For value=, CRs and LFs are preserved as written, both real and NCRs. Personally, I think attribute values should be parsed the same way as data is parsed wrt linebreaks. I agree. I oppose. When I want to define a paragraph-style tool-tip, I am left with the following choice: either make the source code unreadable by making an excessively long line (this is also true for URI attributes but they are not expected to be readable) or make the tool-tip ugly by inserting line breaks. (It cannot be done in an portable way because the width of the tool-tip window and the fount metrics at the viewer's UI are unknown). I recommend: convert line feeds to spaces, use #8232; and #8233; where appropriate, use #10;, #13; where necessary (these should not be converted to spaces). Chris
Re: [whatwg] several messages about the HTML syntax
On Mon, 3 Mar 2008, Krzysztof Żelechowski wrote: When I want to define a paragraph-style tool-tip, I am left with the following choice: either make the source code unreadable by making an excessively long line (this is also true for URI attributes but they are not expected to be readable) or make the tool-tip ugly by inserting line breaks. (It cannot be done in an portable way because the width of the tool-tip window and the fount metrics at the viewer's UI are unknown). I recommend not making paragraph-long tooltips. That's terrible user interface. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages about the HTML syntax
On 03/03/2008, Ian Hickson [EMAIL PROTECTED] wrote: On Mon, 3 Mar 2008, Krzysztof Żelechowski wrote: When I want to define a paragraph-style tool-tip, I am left with the following choice: either make the source code unreadable by making an excessively long line (this is also true for URI attributes but they are not expected to be readable) or make the tool-tip ugly by inserting line breaks. (It cannot be done in an portable way because the width of the tool-tip window and the fount metrics at the viewer's UI are unknown). I recommend not making paragraph-long tooltips. That's terrible user interface. But how will we read the asides on xkcd.com ?! (i.e.: If people can do something, they will, and this needs to be allowed for. ASCII art in tooltips hits my wrong button, but it's out there. OTOH I've never seen a tooltip in a monospaced font. User-agents treating all whitespace as spaces and reformatting as nicely as they can would be fine to me. I'm sure others will come up with real-life use cases for ridiculously long tooltips.) - d.
Re: [whatwg] several messages about the HTML syntax
David Gerard wrote: On 03/03/2008, Ian Hickson [EMAIL PROTECTED] wrote: On Mon, 3 Mar 2008, Krzysztof Żelechowski wrote: When I want to define a paragraph-style tool-tip, I am left with the following choice: either make the source code unreadable by making an excessively long line (this is also true for URI attributes but they are not expected to be readable) or make the tool-tip ugly by inserting line breaks. (It cannot be done in an portable way because the width of the tool-tip window and the fount metrics at the viewer's UI are unknown). I recommend not making paragraph-long tooltips. That's terrible user interface. But how will we read the asides on xkcd.com ?! (i.e.: If people can do something, they will, and this needs to be allowed for. ASCII art in tooltips hits my wrong button, but it's out there. OTOH I've never seen a tooltip in a monospaced font. User-agents treating all whitespace as spaces and reformatting as nicely as they can would be fine to me. I'm sure others will come up with real-life use cases for ridiculously long tooltips.) The current spec doesn't forbid paragraph-style tooltips. It just doesn't pander to them. This seems like a very good tradeoff. / Jonas
Re: [whatwg] several messages about the HTML syntax
On Sun, 2 Mar 2008 23:02:07 + (UTC), Ian Hickson wrote: On Sat, 15 Sep 2007, Henri Sivonen wrote: Currently, unquoted attributes may start with a = [as in img alt==Foobar src='404'] This means that the notion of conformance fails to catch what is most likely an error: [...] To make the notion of conformance more useful for authors (that is, to make conformance checking catch unintentional stuff), I suggest making starting an unquoted attribute value with a = a parse error. Done. On Mon, 17 Sep 2007, Øistein E. Andersen wrote: An alternative solution would be to require that unquoted attribute values not contain (single or double ASCII) quotes. Done. I really meant to say that disallowing quotation marks in unquoted attribute values would make conformance checkers able to detect the particular error pointed out by Mr Sivonen even without disallowing equals signs. (The editor may well have noticed this, but his answer does not reflect this.) Other potential authoring mistakes pointed out since support the case for disallowing quotation marks. I am still not convinced about the usefulness of disallowing equals signs, but I have not considered the issue of which characters should be allowed or not in any detail. -- Øistein E. Andersen
Re: [whatwg] several messages about handling encodings in HTML
On Fri, 29 Feb 2008 01:21:20 + (UTC), Ian Hickson wrote: (I've made the characters not allowed in XML also not allowed in HTML, with the exception of some of the space characters which we need to have allowed for legacy reasons.) The C1 character U+0085 NEXT LINE (NEL) is also a Unicode space character, and this one is neither disallowed nor discouraged in XML as far as I can tell. I am not sure if we really want to support this character, though; Opera, Safari and Firefox do not seem to recognise it at all, and one IE7 installation seems to treat it as a non-breakable wide space, but this may well be font-dependent. (Allowing this character could be confusing given that #x85; does not refer to U+0085, but rather to an ellipsis for compatibility with Windows-1252.) More importantly, the current draft seems to allow C0 (not only white space) controls and delete, as well as U+FDD0 to U+FDDF and the non-characters *FE and *FF when these are expressed as character references. Would it be possible to (dis)allow the same set of characters in both cases? -- Øistein E. Andersen
Re: [whatwg] several messages about the HTML syntax
Executive summary: * Changed the rang; and lang; entities (which we'd already changed anyway) to something more appropriate. (r1286) * Made a number of things parse errors to allow conformance checkers to catch common attribute mistakes. (r1292, r1293, r1299, r1303) * Made a number of changes to parsing for compatibility reasons: entities no longer get parsed betwen comments in RCDATA elements, three more ways to trigger quirks mode, made DOCTYPE parsing not trigger quirks mode if there's trailing garbage (r1294, r1302, r1306) * Made entities at the end of an attribute be not a parse error. (r1296) * A number of editorial changes. (in range r1286 - r1307) On Fri, 29 Jun 2007, Henri Sivonen wrote: On Jun 29, 2007, at 11:59, Simon Pieters wrote: U+003E GREATER-THAN SIGN () Parse error. Set the DOCTYPE token's correctness flag to incorrect. Emit that DOCTYPE token. Switch to the data state. Should the string (public id or system id) that was being built be dropped on the floor as well? On Fri, 29 Jun 2007, Simon Pieters wrote: I don't see a good reason to drop it. The doctype's correctness flag is set to incorrect anyway. But I don't feel strongly about it either way. Agreed. On Fri, 29 Jun 2007, Simon Pieters wrote: IE seems to not emit the token for that is in quotes anywhere for both doctypes and bogus comments (or it treats doctypes as bogus comments): !doctype ! ? / This does not apply to these: !-- -- -- % % % Yeah, I don't think we want to capture IE's complex rules here. On Sun, 1 Jul 2007, �istein E. Andersen wrote: HTML5 currently maps lang; and rang; to U+3008 LEFT ANGLE BRACKET, U+3009 RIGHT ANGLE BRACKET, both belonging to `CJK angle brackets' in U+3000--U+303F CJK Symbols and Puntuation. HTML 4.01 maps them to U+2329 LEFT-POINTING ANGLE BRACKET, U+232A RIGHT-POINTING ANGLE BRACKET from `Angle brackets' in the range U+2300--U+23FF Miscellaneous Technical. Unicode 5.0 notes: These are discouraged for mathematical use because of their canonical equivalence to CJK punctuation. It would probably be better to use U+27E8 MATHEMATICAL LEFT ANGLE BRACKET, U+27E9 MATHEMATICAL RIGHT ANGLE BRACKET from `Mathematical brackets' in U+27C0--U+27EF Miscellaneous Mathematical Symbols-A, characters that did not yet exist when HTML 4.01 was published. I've made this change. This approach is suggested by http://unicode.org/Public/math/revision-09/MathMap-9.txt: 27E8; lang; ISOTECH;** # #10216; MATHEMATICAL LEFT ANGLE BRACKET 27E9; rang; ISOTECH;** # #10217; MATHEMATICAL RIGHT ANGLE BRACKET Moreover, the (few) browsers I have tested render lang/rang, #x2329/#x232a and #x27e8/#x27e9 identically or simalarly (as / in approximative ASCII), whereas #x3008/#x3009 are rendered as full-width East-Asian characters ( / ). The browsers I tested were not at all consistent. On Sun, 1 Jul 2007, L. David Baron wrote: What's wrong with these mappings, and why shouldn't they also be the mappings in HTML5? On Sun, 1 Jul 2007, �istein E. Andersen wrote: The problem is that they are canonically equivalent to CJK characters. On Sun, 1 Jul 2007, L. David Baron wrote: Makes sense. I think I misread your original message. (Although changing them at all seems a little scary.) Well, we'd changed them anyway (since before they mapped to non-canonical characters); changing them to something better seems at least partially sensible... Browsers are pretty poor on these two entities anyway. On Fri, 6 Jul 2007, Simon Pieters wrote: On Fri, 22 Jun 2007 04:19:53 +0200, Ian Hickson [EMAIL PROTECTED] wrote: a == Safari, Opera and Firefox drop the attribute. IE has an attribute with the name being the empty string and the value being =. The HTML5 parsing spec says that there should be an attribute with the name = and the value the empty string. The Before attribute name state part of the parsing spec might have to be revisited. I don't see any harm in leaving the spec as-is here, given the lack of interoperability and the fact that there's no real reason to be using attributes with this name anyway. Whatever's simplest to implement is probably best here. Since it doesn't match any browser, and probably is an authoring mistake (that would silently pass conformance checking in the case of embed), could it be a parse error? (Also update the wording in the syntax section if so.) Done. On Mon, 16 Jul 2007, Henri Sivonen wrote: In the Data State the spec says: U+0026 AMPERSAND () When the content model flag is set to one of the PCDATA or RCDATA states: switch to the entity data state. Otherwise: treat it as per the anything else entry below. html5lib tests, WebKit trunk, Firefox 2.0.0.4 and
Re: [whatwg] several messages about handling encodings in HTML
Dnia 29-02-2008, Pt o godzinie 01:21 +, Ian Hickson pisze: In 8.2.2.4, I have no idea what's the reason or purpose of point 1, which reads If the new encoding is UTF-16, change it to UTF-8.. I suspect some misunderstanding. This is required because many pages are labelled as UTF-16 but actually use UTF-8. For example: http://www.zingermans.com UTF‒16 cannot be transmitted over Internet anyway so it must be changed to something because what comes in is certainly not UTF‒16-encoded. This declaration is in error; one of the possible universal encodings UTF‒8, UTF‒16LE and UTF‒16BE should be chosen that produces valid markup for the decoded document. Chris
Re: [whatwg] several messages about content sniffing in HTML
On 29 Feb 2008, at 16:33, Julian Reschke wrote: Geoffrey Sneddon wrote: It seems like the HTTP spec should define how to handle that, but the HTTP working group has indicated a desire to not specify error handling behaviour, so I guess it's up to us. IE and Safari use the first one, Firefox and Opera use the last one. I guess we'll use the first one. Isn't the fact that FF and IE disagree here an indication that this doesn't need to be specified? Things aren't specified well enough until I can write an HTTP UA that can work in the real world (which, as someone dealing with feeds, I can tell you need without question support for content- type sniffing) from reading specifications without having to reverse-engineer anything. ... Doesn't seem to apply to this case. A duplicate Content-Type header response indicates that the response is invalid. And guess what? Users don't like error messages. I want to know how to deal with it without having to look elsewhere (from the spec). Apparently, most browsers accept the response anyway, some of which picking the first value, others the second. Both behaviors seem to be acceptable to users. So there's nothing you *need* to reverse engineer in this case. A page (http://www.toledoblade.com/apps/pbcs.dll/section?Category=RSS01mime=XML ) that I came across recently had: Content-Type: XML Content-Type: text/XML Using the first would break badly. I guess it seems to work because of content-type sniffing on an unknown (and invalid) header (or, as many feed readers do, totally ignoring it, with the exception of any charset parameter). Without content-type sniffing, that HTML 5 now allows, you need the last. But as James says: how do I know that which behaviour I choose doesn't matter until I reverse engineer browsers to discover that? -- Geoffrey Sneddon http://gsnedders.com/
Re: [whatwg] several messages about content sniffing in HTML
Geoffrey Sneddon wrote: Content-Type: XML Content-Type: text/XML Using the first would break badly. I guess it seems to work because of content-type sniffing on an unknown (and invalid) header Or because the header parser uses the first header that actually looks like a valid content-type (e.g. contains a '/'). Specifying this _is_ needed. -Boris
Re: [whatwg] several messages about handling encodings in HTML
On 29 Feb 2008, at 01:21, Ian Hickson wrote: - Again there, shouldn't we be given unicode codepoints for that (as it'll be a unicode string)? Not sure what you mean. This is just me being incredibly dumb. Ignore it. On Sat, 26 May 2007, Henri Sivonen wrote: The draft says: A leading U+FEFF BYTE ORDER MARK (BOM) must be dropped if present. That's reasonable for UTF-8 when the encoding has been established by other means. However, when the encoding is UTF-16LE or UTF-16BE (i.e. supposed to be signatureless), do we really want to drop the BOM silently? Shouldn't it count as a character that is in error? Do the UTF-16LE and UTF-16BE specs make a leading BOM an error? If yes, then we don't have to say anything, it's already an error. If not, what's the advantage of complaining about the BOM in this case? I don't see anything making a BOM illegal in UTF-16LE/UTF-16BE, in fact, the only mention I find of it with regards to either in Unicode 5.0 is In UTF-16(BE|LE), an initial byte sequence (FE FF|FF FE) is interpreted as U+FEFF zero width no-break space. I suppose the rational given for removing it is the section that follows D101 (e.g., When converting between different encoding schemes…UTF-8 byte sequences is not recommended by the Unicode Standard.). -- Geoffrey Sneddon http://gsnedders.com/
Re: [whatwg] several messages about figure and related subjects
Dnia 27-02-2008, Śr o godzinie 08:06 -0500, Michel Fortin pisze: Now, suppose you have this: pA header looks like this in your browser:/p h1Some text!/h1 ... unfortunately, the h1 here isn't a real header in the document: it's an illustration of a header (ah-ha: figure!) which can't be removed from te flow of the document (oops, can't use figure). There's no rational way to markup this with the current wording of the spec; abusing figure is the most reasonable option I can find: pA header looks like this in your browser:/p figureh1Some text!/h1/figure The problem being that figure needs the ability to be moved around without changing the meaning of the document, so the markup above would be non-conforming because the sentence just makes no sense if you put the figure elsewhere. Perhaps figure could have an optional anchored attribute to indicate it belongs to a specific point in the document. If the page has a header, you can refer the reader to its ordinary header instead. The purpose of headers is to make looking around the page easier; your sample header would be a distraction if it is styled like a normal header and would not make a good demonstration if it is not. Chris
Re: [whatwg] several messages about serialising HTML and related subjects
Executive summary: I did most of the changes suggested below. On Wed, 15 Aug 2007, Simon Pieters wrote: The spec says: Other nodes types (e.g. Attr) cannot occur as children of elements. If they do, this algorithm must raise an INVALID_STATE_ERR exception. s/elements/elements or documents/ as the algorithm can be used for documents as well. What about PIs? They can occur as children of elements or documents. How? On Wed, 15 Aug 2007, Simon Pieters wrote: The serializing HTML fragments algorithm talks about child node to refer to the current node being processed. This is a bit confusing, and I think current node would be clearer. Done. On Thu, 16 Aug 2007, Lachlan Hunt wrote: There is a possible issue serialising HTML fragments section [1]. The algorithm seems fine for use with things like innerHTML, but there are other issues that should be considered when serialising to a file, database, network stream or something. Such serialisers should consider the character encoding. Although a Unicode encoding should ideally be used, some serialisers may need to serialise to a different encoding at the request of the user or limitations of the environment. In such cases, the serialisation should output appropriate character references for characters that can't be represented. It should also handle outputting the appropriate meta charset= and/or BOM, especially in environments that can't declare it at the transport level like HTTP can. Perhaps the spec should say something about this issue somehwhere. [1] http://www.whatwg.org/specs/web-apps/current-work/#serialising The section is specifically for serialising a subtree to a Unicode stream without mutation, not to a byte stream. What's the use case that isn't covered by 8.1 Writing HTML documents? On Mon, 27 Aug 2007, Simon Pieters wrote: IE7 and Firefox serialize U+00A0 characters in data and attribute values as nbsp; when getting innerHTML. Safari and Opera don't. Should the spec be aligned with IE7 and Firefox here? http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0D%0A%3Cscript%3Ewindow.onload%3Dfunction%28%29%7Bw%28document.body.innerHTML%29%7D%3C/script%3E%3Cp%20title%3D%22x%A0x%22%3Ex%A0x I don't see any great benefit to doing so; do any pages require this? On Tue, 28 Aug 2007, Alexey Proskuryakov wrote: This has caused a compatibility issue for WebKit at least once. In that case, we got away with evangelizing, but we still track this as a bug that needs to be fixed eventually. http://bugs.webkit.org/show_bug.cgi?id=11947 Ah. Ok then. Done. On Tue, 28 Aug 2007, Boris Zbarsky wrote: For what it's worth, the relevant Mozilla bugs are https://bugzilla.mozilla.org/show_bug.cgi?id=165686 and https://bugzilla.mozilla.org/show_bug.cgi?id=169590 Cool, thanks. On Tue, 11 Sep 2007, Simon Pieters wrote: Consider the following document: h:p xmlns:h=http://www.w3.org/1999/xhtml;x//h:p When getting innerHTML on the root element, should the serialization declare the no namespace explicitly as in x xmlns=/? (I think it should because setting innerHTML will imply namespace declarations so it might change meaning if you insert it somewhere else with innerHTML.) I've added this: | If any of the elements in the serialisation are in the null namespace, | the default namespace in scope for those elements must be explicitly | declared as the empty string. Is that ok? Also, the spec says: In an XML context, the innerHTML DOM attribute on HTMLElements and HTMLDocuments, on getting, must return a string in the form of an internal general parsed entity [...] ...and then goes on to say that some DocumentType nodes must raise an exception, however internal general parsed entities can't have doctypes in the first place. Oops. Fixed. Only elements should return internal general parsed entities; documents should return document entities. Empty documents now raise an exception. Finally, the spec lists the following as something that throws: A Text node whose data contains characters that are not matched by the XML Char production. [XML] But Text data is not the only case that might not match the Char production in XML. Comment data, CDATASection data, ProcessingInstruction target, and, I think, Attr value. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages about figure and related subjects
Le 2008-02-25 à 17:42, Ian Hickson a écrit : On Mon, 16 Jul 2007, Michel Fortin wrote: Since I'm not convinced that the current content model for figure is adequate [1], I decided to dig more examples where figures in HTML pages would be hard to fit with the current model. Here are the results. Thank you hugely for this research! This is very useful. I have updated the spec to handle these cases, and given examples of some of the key ones. Let me know if you think anything else deserves an example. I'm glad it was helpful. I quite like the new definition for figure and I think it covers the vast majority of illustration use cases I could come with. I don't think it needs more examples either. I'm wondering however about the definition leaving something out. It says: The figure element represents some prose content, optionally with a caption, which can be moved away from the main flow of the document without affecting the document's meaning. Now, suppose you have this: pA header looks like this in your browser:/p h1Some text!/h1 ... unfortunately, the h1 here isn't a real header in the document: it's an illustration of a header (ah-ha: figure!) which can't be removed from te flow of the document (oops, can't use figure). There's no rational way to markup this with the current wording of the spec; abusing figure is the most reasonable option I can find: pA header looks like this in your browser:/p figureh1Some text!/h1/figure The problem being that figure needs the ability to be moved around without changing the meaning of the document, so the markup above would be non-conforming because the sentence just makes no sense if you put the figure elsewhere. Perhaps figure could have an optional anchored attribute to indicate it belongs to a specific point in the document. Note that there was a couple of such markup rendering examples like these at the end of the email you're referring to. Now, perhaps that case isn't important or frequent enough to justify adding it to the spec -- I won't be the juge of that -- but I have myself such a page on my website for which I'd like to use better markup than div class=html at each example (page included in the list in the old email) and I still don't see what I should use (was hoping for figure). It could also be useful to allow labeling of subfigures, perhaps like this: figure figurelegend(a)/legend img .../figure figurelegend(b)/legend img .../figure legendMy house seen (a) from the front; (b) from the back/ legend /figure This is allowed, but I haven't included an example. I don't think it's necessary. Michel Fortin [EMAIL PROTECTED] http://michelf.com/
Re: [whatwg] several messages about section, p, hr, and related subjects
Le 2008-02-27 à 2:17, Ian Hickson a écrit : On Thu, 6 Apr 2006, Michel Fortin wrote: Le 6 avr. 2006 à 6:44, Alexey Feldgendler a écrit : This heading shouldn't be within the document's main tree of headings. It should be completely taken out, that's what aside means. But it can't be done in a backwards compatible way. Hum, that's true; it seems to be a general issue with asides, not limited to figures. Using aside to indicate a sidebar on a page shouldn't be much of a problem because the sidebar is usually outside of the main content and can have the same heading level as the main content. But aside content inserted in the middle of the text is already problematic from the semantic standpoint in HTML 4, and become a problem to any outliner if it contains headers. Maybe there could be a h element. This way you can use h1, h2, etc. for the main content and h for any content outside the main outline of the document, like asides. Its use wouldn't be mandatory, just like you don't have to use the right heading number anymore, but recommended for aside backward compatibility with outliners. It could also be used in the main content for the 7th heading level and beyond. I don't understand the problem being described here. The idea was to add h for use inside aside so you can remove the header from the main flow for old outliners not supporting the HTML5 outline algorithm. I don't think it has a very strong use-case; I was simply pointing it as a solution to the backward compatibility problem Alexey mentioned. Michel Fortin [EMAIL PROTECTED] http://michelf.com/
Re: [whatwg] several messages about figure and related subjects
On Wed, 27 Feb 2008, Michel Fortin wrote: I'm wondering however about the definition leaving something out. It says: The figure element represents some prose content, optionally with a caption, which can be moved away from the main flow of the document without affecting the document's meaning. Now, suppose you have this: pA header looks like this in your browser:/p h1Some text!/h1 ... unfortunately, the h1 here isn't a real header in the document: it's an illustration of a header (ah-ha: figure!) which can't be removed from te flow of the document (oops, can't use figure). There's no rational way to markup this with the current wording of the spec; abusing figure is the most reasonable option I can find: pA header looks like this in your browser:/p figureh1Some text!/h1/figure The problem being that figure needs the ability to be moved around without changing the meaning of the document, so the markup above would be non-conforming because the sentence just makes no sense if you put the figure elsewhere. Perhaps figure could have an optional anchored attribute to indicate it belongs to a specific point in the document. Using figure here doesn't help. What you are illustrating in this case isn't what a header looks like, it's a section that happens to have a header. In fact the only difference between this case and the first example above is that the first example above breaks the outline, but you could work around that by doing this: pA header looks like this in your browser:/p sectionh1Some text!/h1/section ...and it would have roughly the same meaning as in the figure case. The problem is that there's no way to mark up content as being metacontent, that is, there's no way to mark up an element as having no semantics but its default presentation. This is a rare edge case which basically only affects tutorials and test cases. We could come up with a feature to annotate markup as being literal or meta rather than working as defined, but I don't see the point. Test cases aren't going to use it because they are trying to fake out the browser into thinking that some particular convoluted case is occuring, and frankly tutorials are better off not using it because otherwise people would copy and paste that without realising it is specific to tutorials. I recommend simply not worrying about it. In cases where you're self-referrentially discussing markup, the document's semantics don't really make sense. But that's ok, I don't think anyone but semantic nerds like us are going to really notice or care. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages about figure and related subjects
On Tue, 26 Feb 2008 06:16:15 +0100, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
On Feb 25, 2008, at 2:42 PM, Ian Hickson wrote:
label
This would preclude any sane way of putting form controls in
legends, which would be bad.
This can't be fixed in the spec.
Is the ability to put form controls in figure captions (let alone more
than one form control) really more important than ability to style them
sanely? Putting a form control in a figure caption seems unlikely to me.
What would you recommend for the am I hot or not and the like? At first
glance, that seems like a reasonable use case to me.
...
A new element would be a neat solution, but frankly I'm out of words to
use, and if we keep adding new ways to mark up titles and captions and
legends and labels, authors aren't going to be able to work out when
they should use each element...
It seems to me that the problems with adding a new element are purely
aesthetic, while the problems with reusing 'legend' are practical and
harm deployment of the new element.
Agreed.
I think our only option is to use legend, and, while in the migration
period, have people use markup like:
figure
legendspan class=legend ... /span/legend
...
/figure
...with styles like:
figure legend, figure .legend { ... }
Yuck. Surely writing legendspan class=legend ... /span/legend
is uglier than writing something like figcaption ... /figcaption.
And the migration period could take more than a decade. Given the
lengths that HTML5 goes to so that it can degrade gracefully, this
sounds like a high price to pay to avoid adding an element.
cheers
chaals
--
Charles McCathieNevile Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [whatwg] several messages about ol, ul, dl, and related subjects
On Mon, Feb 25, 2008 at 10:29 PM, Ian Hickson [EMAIL PROTECTED] wrote:
On Thu, 8 Feb 2007, Jorgen Horstink wrote:
On Feb 8, 2007, at 9:00 PM, David Latapie wrote:
On Thu, 8 Feb 2007 19:17:32 +, Nicholas Shanks wrote:
On 6 Feb 2007, at 07:57, Karl Dubost wrote:
unlikely. div and span elements didn't exist in HTML+.
http://www.w3.org/MarkUp/HTMLPlus/htmlplus_1.html
Ironically I was just reading that earlier today, then saw your
post! (I hadn't been reading this thread.)
I wish the imagefallback/image tags had made it through the
years. It's so much better than img alt=blah and doesn't
suffer
from the self-closing-tag-in-html problem.
HTML 3.0 too had some great ideas. I'm still missing
- FN (but CSS3 has something about footnote that may fix this)
- LH (caption for list! A must-have)
Why not using the title attribute?
Actually with figure the lh element is now better handled using
figure and legend.
Using figure and legend:
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cscript%3Edocument.createElement('figure')%3C%2Fscript%3E%3Ctitle%3ETitle%3C%2Ftitle%3E%3Cp%3E...%3C%2Fp%3E%0A%3Cfigure%3E%0A%20%20%3Clegend%3EList%20title%3C%2Flegend%3E%0A%20%20%3Cul%3E%0A%20%20%20%20%3Cli%3EList%20item%3C%2Fli%3E%0A%20%20%20%20%3Cli%3EList%20item%3C%2Fli%3E%0A%20%20%20%20%3Cli%3EList%20item%3C%2Fli%3E%0A%20%20%3C%2Ful%3E%0A%3C%2Ffigure%3E
While this isn't horrible, it isn't supported properly, as noted before. FF
currently just ignores the fact that there's a legend tag at all and
treats the list title as a plain text node. IE7 treats the legend as an
unknown tag and the title as a plain text node, even if you try to apply the
createElement shim.
Using lh:
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cscript%3Edocument.createElement('lh')%3C%2Fscript%3E%3Ctitle%3ETitle%3C%2Ftitle%3E%3Cp%3E...%3C%2Fp%3E%0A%20%20%3Cul%3E%0A%20%20%20%20%3Clh%3EList%20title%3C%2Flh%3E%0A%20%20%20%20%3Cli%3EList%20item%3C%2Fli%3E%0A%20%20%20%20%3Cli%3EList%20item%3C%2Fli%3E%0A%20%20%20%20%3Cli%3EList%20item%3C%2Fli%3E%0A%20%20%3C%2Ful%3E%0A
On the other hand, lh seems to be supported just fine in FF *and* IE7
(with the shim). This solution is usable *immediately*, which is a big
plus. Since we only want to allow a single header per list, though, I'd
prefer fully embracing the parallel with table and naming this element
lhead, thus implying it must come first and at most once.
At this point, though, why not just bend the definition of ul and ol and
allow hx tags directly? Both FF and IE7 form good DOM trees with this
markup.
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cscript%3Edocument.createElement('lhead')%3C%2Fscript%3E%3Ctitle%3ETitle%3C%2Ftitle%3E%3Cp%3E...%3C%2Fp%3E%0D%0A%20%20%3Cul%3E%0D%0A%20%20%20%20%3Ch1%3EList%20title%3C%2Fh1%3E%0D%0A%20%20%20%20%3Cli%3EList%20item%3C%2Fli%3E%0D%0A%20%20%20%20%3Cli%3EList%20item%3C%2Fli%3E%0D%0A%20%20%20%20%3Cli%3EList%20item%3C%2Fli%3E%0D%0A%20%20%3C%2Ful%3E%0D%0A
This solution doesn't seem to have a drawback, really. It's already
supported (*without* an IE shim), doesn't require the creation of a new
element, and is completely intuitive. Just specify (like thead) that it
must be at the start of the list, and can occur at most once.
At this point, of course, one must wonder why we don't just stick with a
conforming idea and pop that hx into the first li. Well, obviously,
this doesn't establish the appropriate semantics. An hx *within* an li
is a header for the content *within* the li, not for the containing list.
Popping the header into the list directly as a first child would establish
this, while allowing you to effortlessly mess with the style via CSS
selectors (ul * to give a uniform look to the contents, ul hx to style
only list headers, etc.). And, as noted, it's already handled uniformly and
appropriately in at least two major browsers, and there is no need to
introduce *another* new element for someone to learn. All you need to do is
adjust the nesting rules for ul and ol slightly (and probably dl and
dialog as well), which only has an effect on validators.
I don't have the ability to check this in Opera and other browsers atm.
Anyone want to step up?
Re: [whatwg] several messages about ol, ul, dl, and related subjects
This e-mail is a reply to all the pending feedback related to lists in HTML5. It covers an array of subjects and contains replies to e-mails from around forty different people, all of whom are bcc'ed, across two mailing lists. When replying please select a single mailing list to reply to, and trim any text you quote to just the relevant parts. Executive summary: * Clarified the meaning of ol, ul, dl. * Added examples. * Tentatively added ol reversed to make reverse lists. We'll remove it if browser vendors don't like it. On Wed, 4 Oct 2006, Simon Pieters wrote: I think the current definition of ol[1] seems slightly too vauge: The ol element represents an ordered list of items (which are represented by li elements). I think ol is a list where the order is significant to the meaning; where the order is emphasized. For lists that happen to be ordered but the order isn't really of a big significance or isn't of higher significance than the global order of the document, ol shouldn't be used IMHO. In essence, I want the definition in HTML5 be more like the spirit in HTML4[2]: An ordered list, created using the OL element, should contain information where order should be emphasized, as in a recipe: [...] Otherwise people might use ol whenever a list happens to be in order, e.g. an A-Z list... That makes sense I guess... Ok, updated. ...or a dialogue. Which brings us to the next point: dialogue. The spec contains an example[3] which suggests that ol is appropriate for dialogue. I'm not convinced that it is. What makes a dialogue a list? While the order of dialogue is important, so is the order of any other paragraphs -- I don't think it should be emphasized in particular. I think I'd mark up the dialogue like this: p citeCostello/cite q Look, you gotta first baseman? /q p citeAbbott/cite q Certainly. /q ... Or, perhaps like this (in XHTML5): p citeCostello/cite blockquote p Look, you gotta first baseman? /p /blockquote /p p citeAbbott/cite blockquote p Certainly. /p /blockquote /p ... dialog now covers this. On Mon, 23 Oct 2006, Henri Sivonen wrote: HTML+ used dl for dialog. As far as default presentation goes, dl is the best fit for marking up dialog. Yet, the semantic markup party line is against it. I think there are two reasons for insisting that dl shouldn't be used for dialogs, i.e. that dl really is a definition list rather than a generic presentational grouping device: 1) Saving face after years of such insistence. 2) Avoiding breaking software that collects term definitions from dls. I am not a fan of #1-style reasoning. My guess is that case #2 is already broken on the real Web. Is there a good reason for not prescribing dl for dialogs? There is now that we have dialog... :-) On Mon, 23 Oct 2006, Mikko Rantalainen wrote: I don't think that it's worth the trouble to declare dl element to be unordered (http://www.whatwg.org/specs/web-apps/current-work/#the-dl). As I see it, it's only to rationalize the #1-style above. Well, once you get rid of dialog from dl, there really isn't a reason for it to be ordered... except when you're using dl as a switch statement-type construction, I guess, which HTML5 does a lot... Hmm. I've updated the spec to handle this. Jukka Korpela has written a somewhat complete article about marking up definitions as http://www.cs.tut.fi/~jkorpela/def.html and possible markup is presented at http://www.cs.tut.fi/~jkorpela/def.html#markup The dl element as we know it today is nowhere powerful enough to express much more than a simple entry with two parts. I think it would be wise to document the real world usage of dl element and *if* we want a specific markup for definitions, we can define something better. Isn't that what we have now? On Thu, 8 Feb 2007, Jorgen Horstink wrote: On Feb 8, 2007, at 9:00 PM, David Latapie wrote: On Thu, 8 Feb 2007 19:17:32 +, Nicholas Shanks wrote: On 6 Feb 2007, at 07:57, Karl Dubost wrote: unlikely. div and span elements didn't exist in HTML+. http://www.w3.org/MarkUp/HTMLPlus/htmlplus_1.html Ironically I was just reading that earlier today, then saw your post! (I hadn't been reading this thread.) I wish the imagefallback/image tags had made it through the years. It's so much better than img alt=blah and doesn't suffer from the self-closing-tag-in-html problem. HTML 3.0 too had some great ideas. I'm still missing - FN (but CSS3 has something about footnote that may fix this) - LH (caption for list! A must-have) Why not using the title attribute? Actually with figure the lh element is now better handled using figure and legend. On Thu, 8 Feb 2007, David Latapie wrote: On Thu, 8 Feb 2007 21:07:49 +0100, Jorgen Horstink wrote: - LH (caption for list! A must-have) Why not using the title
Re: [whatwg] several messages about figure and related subjects
On Feb 25, 2008, at 2:42 PM, Ian Hickson wrote:
label
This would preclude any sane way of putting form controls in
legends, which would be bad.
This can't be fixed in the spec.
Is the ability to put form controls in figure captions (let alone more
than one form control) really more important than ability to style
them sanely? Putting a form control in a figure caption seems unlikely
to me. Even more so for details, where form controls inside the
label would be confusingly inside another interactive element. Indeed,
details is arguably a kind of form control.
legend
Parsing issues in Firefox and IE:
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cscript%3Edocument.createElement(%27figure%27)%3C%2Fscript%3E%3Ctitle%3ETitle%3C%2Ftitle%3E%3Cp%3E...%3C%2Fp%3E%0A%3Cfieldset%3E%0A%20...%0A%20%3Cfigure%3E%0A%20%20%3Clegend%3Efigure%3C%2Flegend%3E%0A%20%20content%0A%20%3C%2Ffigure%3E%0A%20...%0A%3C%2Ffieldset%3E
...and the element doesn't appear in the DOM when there's no
fieldset in at least Safari and Firefox.
This is quite the messy situation.
I think we should discount dt, h1-h6, header, div, and p
right
off the bat, since they would confuse matters greatly. We should
similarly
discount title, caption, th, dt, and label, because the
problems
with those can't be fixed.
That leaves legend, or inventing a new element. Both options are
unappealing.
One of the advanages with legend is that while the parse issues
today
are messy, we can fix those (indeed the spec now has them fixed
already,
though we might want to consider making legend close p tags).
A new element would be a neat solution, but frankly I'm out of words
to
use, and if we keep adding new ways to mark up titles and captions and
legends and labels, authors aren't going to be able to work out when
they
should use each element. Various people suggested various element
names in
the e-mails below, but from the names proposed it should be clear
that we
are scarping the bottom of the barrel. I'd rather have a cleaner
solution
for something that could be with us for years to come.
It seems to me that the problems with adding a new element are purely
aesthetic, while the problems with reusing 'legend' are practical and
harm deployment of the new element.
I think our only option is to use legend, and, while in the
migration
period, have people use markup like:
figure
legendspan class=legend ... /span/legend
...
/figure
...with styles like:
figure legend, figure .legend { ... }
Yuck. Surely writing legendspan class=legend ... /span/
legend is uglier than writing something like figcaption ... /
figcaption. And the migration period could take more than a decade.
Given the lengths that HTML5 goes to so that it can degrade
gracefully, this sounds like a high price to pay to avoid adding an
element.
4) Another alternative would be using a new unknown element. Whipping
out my thesaurus, I see rubric, inscription. Another
possibility is
something like figcaption (to avoid the problems caption would
cause
for figures inside tables), but that wouldn't be a good fit for
details.
figcaption and detailscaption and so on just seems like it would
make
the language really complicated.
But rubric is pretty reusable and about as semantically correct as
legend for general use as a caption:
http://dictionary.reference.com/browse/rubric
http://dictionary.reference.com/browse/legend
I agree that the multiplicity of single-purpose elements for seemingly
similar purposes is confusing. But HTML is already well down this
road. I think introducing a new element that's intended to be reusable
for similar contexts would be cleaner than trying to force reuse of
what was meant to be a special-purpose element.
We've waited years for figure, can't we wait a few more while
browsers
get their act together in their parsers?
figure could be used right now with CSS styling as backup and
without polluting up the markup if it didn't rely on an aspect of the
HTML5 parsing algorithm that no browser implements yet. Otherwise we
will indeed have to wait years, needlessly.
Regards,
Maciej
Re: [whatwg] several messages about event-source and related subjects
Sorry about the three-way cross-post, but this message contains replies to e-mails from those three mailing lists. Please select just the one mailing list when replying, and trim the quotes below to include only what you are discussing. Thanks. Executive summary: * Made it possible to adjust the reconnection timeout. * Made it so that the client tells the server what the last message it received was when it reconnects, so as to allow seamless continuation. * Rewrote the implementation processing requirements. * Simplified the event stream format: - removed the concept of 'commands' - changed the comment syntax from starting with a ';' to starting with a ':' * Removed the possibility to control anything of the event other than the 'data' and 'type' of the event. * Restricted the events that can be fired to all use MessageEvent. * Made 'message' events not bubble. * Made the MIME type of the new event stream format be text/event-stream; removed mention of the old format's type (application/x-dom-event-stream). In 2006, Anne wrote, in an e-mail I apparently lost, but which he later reminded me of: * The event-source element has no DOM interface while it has some attributes that probably warrant one. This got fixed at some point. * The specification doesn't define when the onevent event handler is invoked nor when the event event is dispatched. They are only defined. It's also unclear which interface they implement, et cetera. This should be fixed now. * A problem with the event-source element is that the resource is loaded before you can attach event listeners to the document. Perhaps the loading should start after the load event is dispatched? Unless the element was inserted into the document of course (that's actually also a bit unclear). If you use src=, just use onmessage= to receive the messages (and only use 'message' events). Alternatively, do it dynamically. * Since event sources can be attached using other ways than using the event-source element the Target field should be amended to take that into account. (Some sentences there don't make sense for an event source attached to an object that is not an event-source element.) Target is gone. * Regarding that, I'd be interested in hearing the use case for allowing any EventTarget to be a source for server-sent events. This was requested by Opera... I'll happily drop it if it's no longer required. I'd like to only make it event-source elements. * Event namespaces throughout should be changed to match DOM Level 3 Events. That basically means that http://www.w3.org/2001/xml-events is gone. No mention of namespaces is left. * Perhaps RemoteEvent should be replaced with a reference to CustomEvent from DOM Level 3 Events which offers the same type of functionality? RemoteEvent is now MessageEvent and this no longer applies. * What happens when the event given in the Event field doesn't match the NCName production as required by DOM Level 3 Events such as in the example in section 7.1.7? (It uses the event stock change.) Nothing. * At the moment the BNF does need error handling because you could have a ; at the start of a line without any data following (or a new line for that matter). That would have been a comment. Now it's an ignored fied. * It might be better to replace the BNF with something similar as the HTML parsing specification currently has. That provides a much more clear processing model. Both are present. * What happens for other line feed characters? Are they treated as fields? Won't that give lots of problems for authors coding in non-Unix formats? HTTP for example allows both. CRLF, CR, and LF, are all allowed now. * For each non-blank, non-comment line, the field name is first taken[...] doesn't cover what happens to command lines. Removed command lines. * The ctrlKey field would be ignored[...] should probably say keyIdentifier as that's what's used in the example. That section is gone now. On Thu, 14 Jun 2007, reed wrote: I was wondering how you mitigate the persistent connection limitations described in RFCs 2068 and 2616 vs server-sent events. It seems the former limits the laters usability. This seems like an HTTP issue. I'm not sure what we can do about it. On Thu, 21 Jun 2007, Anne van Kesteren wrote: If want to send XML or HTML documents from the server using server-sent events you have to escape them in some way and then unescape them again on the client side. For sending documents it would be more useful if you could specify something like the length of the chunk of data and a MIME type followed by the actual data and that on the client side you just have an attribute on the event that gives you the DOM representation of the document similar to what XMLHttpRequest already has. Specifying a new format besides application/x-dom-event-stream is probably
Re: [whatwg] several messages about hr and related subjects
Ian Hickson: On Wed, 8 Jun 2005, Christoph Päper wrote: Ian Hickson: On Mon, 23 May 2005, Christoph Päper wrote: I almost didn't remember I was so vigorously against |hr|. Everything inside a 'div' belongs together somehow and everything that shares a class (...) is related to each other somehow. You cannot know /how/, but /that/. I still believe in these implicit semantics. For a structure like section p+ there are three kinds of grouping |p|s: - Enclosure* section div+ p+ - Association* section p.foo+ p.bar+ - Separation* section p+ hr/ p+ I consider the first natural, the second more flexible but weaker and the third visual. For it's already there, it's pragmatic to retain the option to use an empty separator. I still don't like it conceptually. * There are better, established names for sure. An hr is equivalent to a p with the content Meanwhile, somewhere else... or similar (...). No, it's not. You are connecting it with the succeeding element instance, but it's not. Anyhow, if it was, why wouldn't you use a 'p' with that content or an empty one? Convenience, clarity. In your opinion today, is |hr| in HTML5 structurally (and semantically) about equivalent to an empty paragraph or to an empty heading? You were comparing it with |p|, but seemed to assign it rather the lead-in function of |h|/|h#|, which could provide ideas for a revised expansion of 'hr' (e.g. heading rudiment). I, on the opposite, think that it's unnatural to mark the end of one thing and the start of a second, but neither the start of the first nor the end of the second. The reason you can do this in a printed work is, that these are *implied* by chapter starts and ends. [DTD stuff snipped] I think it is unrealistic to expect most authors to think this way. Really? If we can get them to think in semantics rather than in visual styles, why would it be harder for them to think in enclosure or association than in separation? (I assume they already understand that a horizontal rule separates two (runs of) elements on the same level.) I disagree that hierarchy need be the way we mark things up here. It makes styling with CSS easier, though. On Thu, 9 Jun 2005, Christoph Päper wrote: Okay, with the goals of WHAT-WG and HTML5 it's maybe acceptable to retain 'hr', but for XHTML2 [it] must go. So I already conceded. It's just like FoobrBar versus Foo/ppBar. The former would be the correct way to mark up an address or poem, though. Each line of an address or poem is not a separate paragraph, it's just a line. I also like enclosing |l| -- |p| was the wrong equivalent here -- better than separating |br| of course.
Re: [whatwg] several messages about address and related subjects
Executive summary: I made it that if address applies to the body element it really applies to the whole document. I did not make address suitable for all contact information; it continues to be limited to contact information for the current section/article/page. I couldn't see a convincing use case for the element either as contact information for the page nor for any arbitrary contact information, and would probably not introduce the element at all if it wasn't for the relatively big existing use base, which, as far as I can tell, is mostly using the element correctly (at least relative to how HTML is generally misused). On Thu, 12 Oct 2006, Simon Pieters wrote: address is currently defined to apply to its nearest ancestor sectioning elements. If you wanted to give contact information for a page you could use an address that applies to body, but that doesn't cover the entire document (e.g., it doesn't apply to the title). Perhaps it could be defined so that when address applies to the body element also applies to the entire document? Done. On Thu, 30 Nov 2006, Simon Pieters wrote: Shouldn't The address element and The figure element sections be moved to the Paragraphs section? Arguably. However, address is related to sections, so seems to belong well there, and figure (for now at least) applies to embedded content, so seems to belong there too. On Mon, 26 Feb 2007, Simon Pieters wrote: From http://forums.whatwg.org/viewtopic.php?t=5 | In HTML4, the address element was defined as this: | | | The ADDRESS element may be used by authors to supply contact | | information for a document or a major part of a document such as a | | form. | -- http://www.w3.org/TR/html4/struct/global.html#edef-ADDRESS | | In WHATWG's HTML5, it's defined as this: | | | The address element represents a paragraph of contact information for | | the section it applies to. | | | | ... | | | | The address element must not be used to represent arbitrary addresses | | (e.g. postal addresses), unless those addresses are contact information | | for the section. | -- http://www.whatwg.org/specs/web-apps/current-work/#the-address | | This seems to be quite a rare scenario to have an element dedicated to. | If it were more general, surely the element would become more useful? | Somewhat like dl being used for more than just dictionary-like | definitions. | | As examples (numbered for convenience): | | * A general point of contact where messages would ultimately get passed |on to the person responsible for the section where the address was |found. | * People or departments responsible for more than that section. | * People or departments of the organisation the website is for, even if |they are not directly responsible for the section in which the |address occurs. (Example: Calthorpe Park School's contact page. [1]) | * Member's profiles in forum and other social network systems, who have |limited control over that section. (They can edit their own contact |details and perhaps other personal information in that section, but |don't work for the website.) | * Providing contact details of any type for any person or organisation. | | It may also be more intuitive that an element with a fairly generic name | like address have fairly generic semantics. | | Are there any implementations which rely on the current semantics? | (AFAIK, there aren't.) | | So then, should address be more general-purpose? (I think it should, | if you hadn't guessed!) | | [1] http://calthorpepark.hants.sch.uk/contact.htm (Ironically, the example given uses it correctly now. :-) ) Making it general purpose means we lose the contact-information angle, which could be an issue... On Tue, 27 Feb 2007, Benjamin Hawkes-Lewis wrote: Would generalizing address to that extent prevent automated agents being able to distinguish an address for a article (e.g. a blog comment) from an address mentioned in a article? This would make it more difficult to construct functionality for citing by or replying to author. Creating an author element might help resolve that problem for new content, but then agents would have to sniff content to work out what sort of content was under investigation. A better alternative might be a new element contactinfo, which is a more general name than address and doesn't make old content more ambiguous. I don't think we want to introduce a new element for this. That's expensive and confusing, and the element isn't that well used as it is. On Tue, 27 Feb 2007, Simon Pieters wrote: Yes. Do UAs need to know the scope of the address? What could they do with this information? (If it is important, then we could use a class name or a new attribute for this IMHO.) address has been around forever. Yet no UA has done anything useful with its semantics as far as I know. That suggests to me that the use-case is
Re: [whatwg] several messages about hr and related subjects
Executive summary: no changes made; not much controversy.
On Sat, 21 May 2005, Rimantas Liubertas wrote:
On 5/21/05, Ian Hickson [EMAIL PROTECTED] wrote:
...
Actually Steven Pemberton gave some interesting examples of what look
to me like valid use cases for hr/ in a recent talk of his. Search
for hr in these slides:
http://www.w3.org/2005/Talks/04-19-steven-XHTML2-XForms/
I don't really see what else to use for those.
I see no point for this even in this case. If you separate _sections_,
then they are already separate and you can style sections themself.
Example: http://rimantas.com/bits/hr/nohr.html
And if hr had any semantic meaning, then it was trasfered to class
attribute ;)
But this isn't necessarily separating sections (chapters). Look at any
book of fiction -- there's definitely a level of separation that is
between paragraphs that is within a section.
Indeed I wrote pretty much that before.
On Mon, 23 May 2005, Mikko Rantalainen wrote, in response to that:
They're not really sections. The chapter is the section, these are
paragraphs together in the same chapter, with a divider between some
of the paragraphs.
I read a lot of fiction books and when I come across a * * * it
reads to me like a paragraph, saying Meanwhile, in a different part
of the universe:; it doesn't read as end section. new section:.
I read the * * * part exactly the same way. And I consider your quoted
text to be the header for that sub-section even though it's omitted from
the output. I feel that the correct markup to use would be
section!-- chapter starts here --
hYet another chapter/h
section!-- 1st point of view, really a subsection --
h class=undisclosedIn the Jack's basement/h
...
/section
section!-- presentation adds * * * here --
h class=undisclosedMeanwhile in the Bill's room/h
...
/section
/section!-- chapter ends here --
I don't think that's the structure. I think the structure is you have a
section (a chapter) and it has paragraphs that are separated.
In my opinion, this is the correct sematics for the content. To increase
excitement for the reader, some of the content is hidden during the
presentation. If you feel that hiding the information is part of the
semantics in this case (arguably that may be true), just drop all the
h elements with class undisclosed above.
I think this is trying to fit typical conventions on a mode of thinking
that doesn't match the typical conventions. I don't think it's really a
good abstraction to use.
I think this is an example of why an h element shouldn't be required
inside a section element.
It's not.
To put it another way, sections are things that you can put a title
to. There's no title you can put to a group of paragraphs separated
from other groups of paragraphs in the same chapter of a work of
fiction, in my experience. It's just the same chapter, with the
narrative exploring different characters or scenes.
I think you can always put a title to a group of paragrahps. It's just
that sometimes (often?) you decide to leave it out for brevity / clarity
/ excitement / whatever.
If you leave it out, it doesn't have a title.
On Thu, 2 Jun 2005, R.J.Koppes wrote:
I too think hr carries semantics, although the tagname implies it's
fot presentaional use. things like divider or seperator sound more
reasonable I think
Too late for that! :-)
I my opinion hr is a divider of content, it makes the content before
and after less bound than without. Speechbrowsers might pause here a
little longer, or play a tune like the ones you hear on the radio,
seperating news items.
I tend to put it between navigation and content, and between content and
some legal stuff at the bottom of the page. Since the seperation is in
many cases already evident, I often hide them, but in textbrowsers such
as lynx, I think it's function is quite clear.
When viewing for example my page without styles applied, I think the use
of hr makes sense.
I agree.
On Fri, 3 Jun 2005, Matthew Raymond wrote:
So what you're saying is that if I want this...
| section!-- chapter starts here --
| hYet another chapter/h
| p[Something about Jack.]/p
| hr
| p[Something about Bill.]/p
| /section!-- chapter ends here --
...then I have to do this?...
CSS:
| .chapter section + section:before {
| content: * * *;
| text-align: center;
| }
HTML:
| section class=chapter!-- chapter starts here --
| hYet another chapter/h
| section!-- 1st point of view, really a subsection --
| h class=undisclosedIn the Jack's basement/h
| p[Something about Jack.]/p
| /section
| section!-- presentation adds * * * here --
| h class=undisclosedMeanwhile in the Bill's room/h
| p[Something about Bill.]/p
| /section
| /section!-- chapter ends here --
Actually, there are situations where the above would be suboptimal,
based on how
Re: [whatwg] several messages
On Fri, 18 Jan 2008, Philip Taylor wrote:
Maybe the desired properties are:
- drawImage(img) onto a displayed canvas should look the same as
the original img, regardless of whether the image has gamma etc.
- toDataURL should return the same raw pixel data as getImageData, at
least for image/png (though other formats might make that impossible),
for consistency.
- drawImage(toDataURL()) should have no effect.
Made explicit.
I'd also like:
- fillStyle = 'rgb(r, g, b)'; fillRect(...); getImageData returns
exactly [r, g, b, 255].
mainly because that makes it possible to write test cases that use
getImageData to check the results.
That was already explicit.
function FillCload(data, x, y) { ... } - should be function
FillCloud(data, x, y) { ... }.
That error was replaced with function AddCload(data, x, y) { ... } - s/a/u/
Fixed.
On Sun, 20 Jan 2008, Henri Sivonen wrote:
[...]
On Sun, 20 Jan 2008, Darin Adler wrote:
[...]
On Sun, 20 Jan 2008, L. David Baron wrote:
[...]
On Sun, 20 Jan 2008, Maciej Stachowiak wrote:
[...]
I didn't see anything in this discussion that I could apply to the spec,
but please do let me know if there's anything in the canvas requirements
that should change (or be added).
Cheers,
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages regarding Ogg in HTML5
On Wed, 12 Dec 2007, alex wrote: We have to take into accounts the needs of everyone. This includes large companies. If large companies will only accept codecs that they've already implemented, then that may have to be one of the criteria. This conflicts with: Whatever solution we find will be one that is royalty free and open. That is not in any doubt. You can't have it both ways. We could, if one of the codecs that was implemented by large companies (e.g. H.264 Baseline) was made available royalty-free. It could also be the case that the aforementioned large companies will accept a compromise that doesn't involve a codec they already implement. Currently there is no known solution. That's why we're in this mess. But, as they say, top people are working on this. If the text moves to requiring a non-free codec, then you will have been screwed, and then you should raise almightly hell. However, no such decision has been made (and no such decision will ever be made, at least not while I'm involved). Pfew, can we get a signed copy of that? :P It's already in the spec: # [...] we need a codec that is known to not require per-unit or # per-distributor licensing, that is compatible with the open source # development model [...] The way i see it there are 3 possibilities so far: - use ogg, possible (but negligable) risk of submarine patents This is basically as acceptable to companies like Apple as H.264 is to the free software community. - use extremely old technology Unfortunately this is unlikely to give us the quality we desire, but it is possible that we will have to compromise on this option. - use another free codec which has a 100% guarantee that there are no patentholders lurking this does not exist (afaik) Indeed. At the end of the day, I think little choice remains except ogg. Ogg isn't a choice, unfortunately. I agree that little choice remains, though. But this is an open issue, and experts in the field are actively trying to resolve it to everyone's satisfaction. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages regarding Ogg in HTML5
Ian Hickson wrote: Ogg isn't a choice, unfortunately. I agree that little choice remains, though. But this is an open issue, and experts in the field are actively trying to resolve it to everyone's satisfaction. Yes, Ogg most certainly is a choice. Every time you deny this, you give more weight for Apple, Nokia, et al to through around. Stop. We do have the choice of saying that Ogg is the way forward, and that if Apple, Nokia, et al don't want to implement it, then they can choose to not be conformant to the new standard. In my mind, this outcome is *far* superior to using a patent encumbered codec, even if the patent holders grant a royalty free license on it since the Ogg family have had so much research done on them that the chances of submarine patents should be at least greatly reduced, if not eliminated. In short, I am absolutely sick and tired of big companies coming in and throwing their weight around in standards organizations and getting their end-user-screwing technologies embedded into supposedly open and free standards. I've watched it happen in the past with the w3c, I've watched it happen repeated in the IETF, I don't think I've ever seen it *not* happen with ISO, ECMA seems *designed* to rubber stamp end-user-screwing technologies. And, yes, Apple, I'm looking at you here too. Your hands are not clean in this from past exercises. No, I don't trust you, yes, I'm going to object loud and long to any move that appears to be moving away from free and open technologies, which is what this is. Yes, I'm pissed. I'm taking an extreme position, but its a position of principle, and I will not back down from it. -- Jeff McAdams They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin signature.asc Description: OpenPGP digital signature
Re: [whatwg] several messages regarding Ogg in HTML5
Ian Hickson wrote: At least with Theora we can avoid any known ones. All codecs have a risk of submarine patents (though with extensive having been done for Theora, at least that risk is lowered, if not eliminated completely), so that argument is a wash, its on both sides of the equation, so it cancels out. Not for companies that have already taken the risk of one of the codecs already. And this is exactly the way that Apple, Nokia, et al are hijacking this process. They throw out some nebulous business reason for why they don't want to use Ogg et al, and it gets bought, hook line and sinker. Maybe there is some legitimacy to that argument, even, but, I really don't care. The w3c should be about making the best free and open standard they can, and right now that means Ogg...if Apple and Nokia don't want to implement that, then that's their problem. If HTML5 doesn't get traction as a result, then you point at Apple and friends and point out that they refuse to implement a perfectly good and easily implementable spec and let the marketplace figure it out. There's no point putting a MUST in the spec if we _know_ that it won't be followed. We're not writing specs to satisfy a theoretical need, we're trying to get actual interoperability across all browsers. Then you've decided to allow any big company to torpedo this process based on some nebulous claims of business risk. So much for the w3c being relevant. I thought the w3c stood for more than this. If you want a baseline that everyone can implement without being encumbered, then the answer is Theora. We have been told that Theora is not something everyone can implement. And that's a bald faced lie. Everyone *can* implement it, though they may choose not to. No way should the w3c be held hostage to that. Small companies aren't targetted by patent trolls. Only big (really big) companies are. It's a big-company concern, just like no per-user licensing is a small-company concern. That's just the reality of the situation, it's not intended to be a bias. Except that it very clearly is biasing the decision making process so far. The language was changed because the big companies weren't comfortable with it, moving in the direction of screwing the little guy. That is bias. I'm sorry you believe that. It really isn't supposed to be. We're trying to find a solution that works for everyone. Then revert the text, even if only as a show of good faith. If you really want this to be a baseline codec that everyone can implement, revert the text and then change it to MUST. Making it a MUST doesn't make it possible for everyone to implement. If only standards development worked that way! It would be far easier. No, what makes it possible for everyone to implement is that its a free and open codec without encumbrances. Making it a MUST in the spec encourages people to implement and allows the market to bring more pressure to bear on it. This is a Good Thing(tm). and that is not an additional submarine patent risk for large companies. You've created the bias in the premise. By including the word additional, there, you have artificially limited the field to codecs which are already implemented by the large companies. That is not progress, that is one great big, huge, gigantic step backward. We have to take into accounts the needs of everyone. This includes large companies. If large companies will only accept codecs that they've already implemented, then that may have to be one of the criteria. That is absurd in the extreme. Its a new spec, any new spec involves new risk. If you aren't willing to take on new risk then HTML5 becomes nothing more than an XSLT transform away from HTML4. But since we're in a standards setting venue, non-standards-compliant browsers (now or future) and, by definition out of scope. Actually, all browsers are in scope to the WHATWG work. It would be short sighted in the extreme, for instance, to ignore IE, since they have a controlling position in the market. That just doesn't make any sense. If a browser decides that its not going to be standards compliant, then there's nothing that the standards body can do to affect what that browser does. The hope with IE is that MS at least makes noises about making IE standards compliant, and with IE7 at least made it less badly broken with respect to standards. I'll give them the benefit of the doubt and say that they're at lesat trying. If a browser maker isn't even going to try, then we can't worry about them. Ogg is _a_ choice, which provides freedom for some but not everyone. We need a codec that works for everyone. Then you might as well give up on HTML5 right now. I hope we can find a solution that doesn't involve giving up. :-) If you continue to let the big companies hijack the process like you have on this issue, then there's no hope. On Tue, 11 Dec 2007, Jeff McAdams wrote: A decision
Re: [whatwg] several messages regarding Ogg in HTML5
On Wed, 12 Dec 2007, Jeff McAdams wrote: Ian Hickson wrote: Ogg isn't a choice, unfortunately. I agree that little choice remains, though. But this is an open issue, and experts in the field are actively trying to resolve it to everyone's satisfaction. Yes, Ogg most certainly is a choice. Every time you deny this, you give more weight for Apple, Nokia, et al to through around. Stop. This isn't a matter of different browser vendors having different weight. What we are looking for here is a solution that addresses the needs of every browser vendor. Ignoring some of the browser vendors isn't an option, whether those browser vendors are Apple and Nokia, or whether they are Opera and Mozilla. We do have the choice of saying that Ogg is the way forward, and that if Apple, Nokia, et al don't want to implement it, then they can choose to not be conformant to the new standard. Our goal here is not to be able to point to browsers and label them as compliant or non-compliant. Our goal is to be able to use video on the Web in a royalty-free manner in a way that interoperably works in _every_ browser, whether from Apple, or Opera, or Mozilla, or Microsoft, or Nokia, or whoever. In my mind, this outcome is *far* superior to using a patent encumbered codec, even if the patent holders grant a royalty free license on it since the Ogg family have had so much research done on them that the chances of submarine patents should be at least greatly reduced, if not eliminated. Ogg Theora has not had an exhaustive patent search (you may be thinking of Ogg Vorbis). In fact, it is likely the case that H.264 has had a _more_ exhaustive patent search than Ogg Theora. If H.264 Baseline was made available royalty-free, why would we _not_ want to use it instead of Ogg Theora? It is technically a far superior codec, it has the same or lower risk of submarine patents, and it would have (by definition given the context within which I am asking the question) the same licensing as Ogg Theora. In short, I am absolutely sick and tired of big companies coming in and throwing their weight around in standards organizations and getting their end-user-screwing technologies embedded into supposedly open and free standards. I understand, but I assure you that that is actually not what is happening here. We are in fact trying to find a solution that doesn't involve screwing over end users. I am sorry if you find it hard to believe that we actually care about end users. And, yes, Apple, I'm looking at you here too. Your hands are not clean in this from past exercises. No, I don't trust you, yes, I'm going to object loud and long to any move that appears to be moving away from free and open technologies, which is what this is. Yes, I'm pissed. I'm taking an extreme position, but its a position of principle, and I will not back down from it. That is your right, but please, when posting to the WHATWG list, keep your tone moderated and your arguments rational. Accusing other participants of being untrustworthy does not help us come to an amicable and acceptable solution, it just antagonises people and makes them less willing to compromise, something which could be fatal in this issue. Dismissing Apple's concerns doesn't help us address Apple's concerns. Apple are not dismissing our requests for a royalty-free codec, we should not dismiss their requests for a codec that doesn't involve unwarranted risks of potentially extremely expensive legal action against them. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages regarding Ogg in HTML5
On Wed, 12 Dec 2007, Jeff McAdams wrote: And this is exactly the way that Apple, Nokia, et al are hijacking this process. They throw out some nebulous business reason for why they don't want to use Ogg et al, and it gets bought, hook line and sinker. Maybe there is some legitimacy to that argument, even, but, I really don't care. Indeed, the actual argument doesn't really matter. The key take-away is that Apple and Nokia don't want to implement Ogg Theora, so, since our goal is full interoperability between all browsers, we can't use Ogg Theora as our common codec. The change in the spec is merely to reflect this. The w3c should be about making the best free and open standard they can, and right now that means Ogg...if Apple and Nokia don't want to implement that, then that's their problem. It actually is our problem too, as it would lead to HTML5's video element being a failure. If HTML5 doesn't get traction as a result, then you point at Apple and friends and point out that they refuse to implement a perfectly good and easily implementable spec and let the marketplace figure it out. The marketplace is likely to figure it out by doing what they've been doing all this time, namely, use Flash (which is moving to H.264). This is a losing proposition if you desire the Web to be based on royalty free standards as I do. There's no point putting a MUST in the spec if we _know_ that it won't be followed. We're not writing specs to satisfy a theoretical need, we're trying to get actual interoperability across all browsers. Then you've decided to allow any big company to torpedo this process based on some nebulous claims of business risk. That is indeed the case, just like we allow small companies to torpedo the process based on some nebulous claims of excessive license fees. That's how standards development works. So much for the w3c being relevant. I thought the w3c stood for more than this. This is the WHATWG, not the W3C. If you want a baseline that everyone can implement without being encumbered, then the answer is Theora. We have been told that Theora is not something everyone can implement. And that's a bald faced lie. Everyone *can* implement it, though they may choose not to. Ok, we have been told that Theora is not something everyone will implement. The net result is the same. Small companies aren't targetted by patent trolls. Only big (really big) companies are. It's a big-company concern, just like no per-user licensing is a small-company concern. That's just the reality of the situation, it's not intended to be a bias. Except that it very clearly is biasing the decision making process so far. The language was changed because the big companies weren't comfortable with it, moving in the direction of screwing the little guy. That is bias. I'm sorry you believe that. It really isn't supposed to be. We're trying to find a solution that works for everyone. Then revert the text, even if only as a show of good faith. Reverting the text doesn't find a solution that works for everyone -- it merely puts forward a solution that we _know_ isn't acceptable to everyone as a fait accompli, which is, as you so finely put it, a bald-faced lie. Actually, all browsers are in scope to the WHATWG work. It would be short sighted in the extreme, for instance, to ignore IE, since they have a controlling position in the market. That just doesn't make any sense. If a browser decides that its not going to be standards compliant, then there's nothing that the standards body can do to affect what that browser does. If the vendor decides to not be standards compliant on principle, then yes, I agree. And such vendors would be ignored. However, Apple has repeatedly shown a true desire to follow standards (e.g. they were the first browser vendor to fix the bugs that the Acid2 test exposed in their rendering engine), and we owe it to them to address their concerns so that they _can_ be compliant. Whatever solution we find will be one that is royalty free and open. That is not in any doubt. Then as a show of good faith, revert the text until the discussion happens. I don't understand how my statement leads to yours. They seem to be non-sequitur. How does having the spec recommend something that we know isn't acceptable to everyone, a show of good faith? As the person who would make that decision, I assure you that no decision has in fact been made. That is, in fact, the entire crux of the issue. But the fact is that the text was changed away from specifying free and open codecs, even if as a default position. And that's offensive. The text went away from specifying a _particular_ free and open codec without the consensus of the group as a whole, to specifying that we need a free and open codec that _does_ have consensus. I do not understand why that would be
Re: [whatwg] several messages regarding Ogg in HTML5
Ian Hickson schrieb: Ogg Theora has not had an exhaustive patent search (you may be thinking of Ogg Vorbis). In fact, it is likely the case that H.264 has had a _more_ exhaustive patent search than Ogg Theora. Well, thanks to VP3 having been a commercial product licensed to numerous commercial entities (e.g. Nullsoft/AOL) the very existance of On2 depended on being clean of patents they don't own. The statement that Theora had no exhaustive patent search is in danger of being inaccurate. Plus as long as no meaningful metric exists defining how exhaustive a patent search has been things are a bit hard to compare anyway. Now, thanks to the commonly accepted ( ;-) ) fact that Vorbis has had an exhaustive patent search: Does that mean that Vorbis is a candidate for a baseline audio codec? Or is the actual extend of any patent search irrelevant? If so: Why is the H.264 patent search relevant? If an exhaustive patent search is a key towards acceptance of any format: Why not commision one? If H.264 Baseline was made available royalty-free, why would we _not_ want to use it instead of Ogg Theora? It is technically a far superior codec, it has the same or lower risk of submarine patents, and it would have (by definition given the context within which I am asking the question) the same licensing as Ogg Theora. I'd say the opposite could just as well apply. H.264 is a sophisticated codec using plenty of state-of-the-art technologies. Thus H.264 may be a much bigger target to submarines than Theora, which quite frankly is a pretty straight-forward coding scheme using well-known concepts without sophisticated bells and whistles. That way or another: Plainly saying that one codec is at higher risk than the other is a rather dangerous adventure.
Re: [whatwg] several messages regarding Ogg in HTML5
Ian, are you saying that not implementing a SHOULD statement in the spec would make a browser non-compliant with HTML5? Are you saying that if a vendor does not implement the OPTIONAL Ogg support then they would not use HTML5 at all? I'm not being sarcastic here. I'd actually like you to answer these points to understand your position on the SHOULD statement. I commend you for trying to support all views but you yourself have indicated that the Ogg vs. H.264 parties cannot agree - and in the absence of an improbable event (the spontaneous appearance of an unencumbered, court tested, high-performance, non-proprietary video codec) never will. Even if Ogg were court-tested Nokia and Microsoft will never change their position while remaining in the MPEG-LA consortium. The only other option then is inaction (your apparent solution) - which we ALL agree will hand the win to Macromedia (97% Flash market share). One of these parties must get their way, and currently the majority of voiced opinion here is that we SHOULD recommend Ogg (as in SHOULD not MUST). As others have said, if Apple and Nokia (the minority of respondents) do want to implement Ogg then there appears to me to be no requirement for them to do so while retaining compliance. There is nothing I see that prevents video being used with other formats. Surely this will not destroy the video element, it will simply require Safari, IE and Nokia users to download a plugin for some sites (which open-source groups will be happy to provide) or use an Ogg compatible browser or 3rd-party app. There is no logical reason we should not *recommend* Ogg while no better options remain. It isn't perfect but it is the best nonetheless. If nothing else it will give the public (this is still a public spec isn't it?) a baseline format for the publishing of non-profit materials that can be decoded by all Internet users (yes, even those on Mac) without restriction. Submarine patents are irrelevent here as we all agree there there is no viable solution for that and there isn't likely to be within the useful lifetime of this specification. As it stands, right now, h.264 is patent-locked, VC1 is patent-locked, Flash is patent-locked, h.261 is too slow, Dirac isn't ready. Ogg is reasonably fast, well tested, well support and NOT patent-locked until somebody proves otherwise. It is not unreasonable to tell browsers they SHOULD support it, even though we know some won't. Apple; How can we make you happy without committing to future h.264 royalties? More specifically, what other royalty-free, non-patented, drm-supporting codec would you prefer? Microsoft/Nokia; Are you even going to support HTML5, when you seem so keen on making your own standards? When have you EVER been fully compliant with a public spec? Ian; Why do you think we are angry with you? What will it take to get this (apparently unilateral) change revoked? Finally, what is Google/YouTube's official position on this? I know that's a lot of questions but I feel they SHOULD be answered rather than simply attacking the Ogg format. Shannon
Re: [whatwg] several messages regarding Ogg in HTML5
(I've been watching the emails fly around with great interest, but there has been a rather significant volume. You'll have to forgive me if the following question has already been answered.) It seems to me that the argument keeps coming back to the fact that H.264/AAC has patent protection available while Theora/Vorbis does not. Thanks to the efforts of the MPEG-LA, Nokia, Apple, and even Microsoft can sleep well at night. However, this raises a question in my mind. MPEG-LA is the administrator of a variety of patent portfolios. Not just the MPEG sphere of patents, but also IEEE 1394 and DVB-T. They are also working to add patent portfolios for VC-1, ATSC, DVB-H, and Bluray. Which means that they are well-equipped to provide patent administration and indemnification for a wide variety of formats. *Has anyone asked MPEG-LA if they'd be willing to provide indemnification for Vorbis/Theora?* While I understand that there is no actual patents to license at this time, a fee to MPEG-LA (enough to cover possible patents in the future + MPEG-LA's standard profit margin) for protection against submarine patents could very well solve this impasse. Any thoughts? Jerason Banes On Dec 11, 2007 3:40 PM, Ian Hickson [EMAIL PROTECTED] wrote: In the absence of IP constraints, there are strong technical reasons to prefer H.264 over Ogg. For a company like Apple, where the MPEG-LA licensing fee cap for H.264 is easily reached, the technical reasons are very compelling.
Re: [whatwg] several messages regarding Ogg in HTML5
Hi Guido, The point of a patent research is to reduce the risk. Since companies seem to be afraid there may be submarine patents and thus Theora expresses a large risk for companies to support it, the way to reduce the perceived risk is to do an independent analysis of the technology incorporated in Theora about patents that it may be infringing. This could be funded through all the interested parties together, including open source/standards organisations like Mozilla or Xiph, but must be undertaken by an independent organisation. The W3C is the right organisation IMHO. As for the mobile argument - Theora has been demonstrated to work on chips using HW acceleration, so I cannot really see a problem with that. Regards, Silvia. On Dec 12, 2007 7:35 PM, [EMAIL PROTECTED] wrote: Silvia, By definition submarine patents are patents nobody knows of, except its owners, who might just wait until a deep pocket company has shipped a considerable amount of products before requesting this company to compensate them for their IP they are using in this product. W3C has no possibility to detect or even prodect from these patents. Pls see our position paper of the W3C Video on the Web workshop. The other issue that might have gotten less attention in recent mailing list and Slashdot discussion is the availability of chipsets that support a considered codec for desktop and embedded environments. Silicon support is essential for battery-powered devices. A pure SW implementation of a codec will be slower and will drain the battery way faster than a codec that relies on HW accelleration. But lets examine the outcome of the W3C workshop. Cheers - Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Silvia Pfeiffer Sent: 12 December, 2007 08:24 To: Dave Singer Cc: WHATWG Proposals Subject: Re: [whatwg] several messages regarding Ogg in HTML5 On Dec 12, 2007 11:38 AM, Dave Singer [EMAIL PROTECTED] wrote: Possible action: The members of the WG are engineers, not IPR experts. There is general consensus that a solution is desirable, but also that engineers are not well placed to find it: a) they are not experts in the IPR and licensing field; b) many of them are discouraged by their employers from reading patents or discussing IPR. It's clear that the December workshop cannot be silent on this subject. There must be recognition of the issue and evidence of at least efforts to solve it, and preferably signs of progress. It is probable that this is best handled in parallel with the technical work, and headed by someone 'technically neutral' and qualified, such as W3C technical and legal staff. A good start would be to: a) examine the declaration, licensing, and patent expiry situation for various codecs; b) contact the licensing authorities for various codecs to determine their level of interest and flexibility, and possibly invite them to the December workshop. c) analyze the open-source codecs for their risk level, and possibly seek statements from patent owners if that is deemed prudent; What was the consensus on the what to do question? I would be quite interested to get c) undertaken and see how real the submarine patent threats are. Is that a real possibility for the W3C to do (I mean: financially speaking)? Also, if there is any potential that large patent owners could make statements about the applicability of their patents to these open specifications, the let's try it! Regards, Silvia.
Re: [whatwg] several messages regarding Ogg in HTML5
Dnia 11-12-2007, Wt o godzinie 18:21 -0500, Manuel Amador (Rudd-O) pisze: That's no reason to NOT SUGGEST Ogg Vorbis / Theora. No one here is saying that HTML5 should forbid proprietary codecs -- all we're claiming for is the judicious and well-deserved mention of two free technologies in a document that will be read by MILLIONS of people to come. And you just killed that. You're exaggerating, you are. If Web developers read the specification (or any specification, for that matter), the Web would not look like it does. But they do not; the prefer Dreamweaver, and whatever you have got. Small companies aren't targetted by patent trolls. Only big (really big) companies are. And therefore they're deserving of more protection? Sounds like a racket to me. I am sorry you perceive them this way. Be honest, don't tell me you're sorry because you are not. You're sorry when something personally sad happens to someone you know, not when there's a perfectly valid disagreement on an action you took. Clairvoyant? I don't care much for the content in my own computer, since I encode my things in free formats and using free technology, but I will care when I start playing videos on my computer and it says to me you need codec X, which unfortunately is not available for your Linux computer. If you keep the section you censored, the likelihood of that happening is much, much lower. Not really. Yes, the big players here are fearful and doubtful of the uncertain patent situation surrounding Ogg. That is in fact the entire problem. How curious that the Ogg Vorbis authors never felt that fear, uncertainty and doubt. Perhaps they didn't because they actually did their homework and researched the patent minefield before stepping on one of those mines, instead of saying it can't be done, we're too afraid? Irrelevant, dismissed. Sure. We will just have to wait till we all have 50 megabits/s at home to watch 320x240 videos or something. Maybe we can convince podcast authors to start casting in RIFF WAVE -- I hear it has awesome quality at 8000 Hz mono! Then don't. Read books, it will do you more good. Sadly there's really no such thing as an exhaustive patent search. There's also no such thing as a perfect prophylactic, yet people still use condoms because they're good enough. That does not mean you can force somebody to use them when he is afraid. It'd be fantastic if someone from Xiph pronounced himself on the matter in this forum. But it would not change anything. Tactics change over time. Anyway, it's not our duty to concern ourselves with the *intentions* of the players (though I did shine some light on the issue because it's good to know what the players want). But it is our duty to reflect over the lasting consequences of our actions. This particular action, as already noted, is temporary and it is not meant to have any. Stalling Ogg for a pie-in-the-sky nonexistent solution is not the answer. Ogg is already working in many browsers (both Vorbis and Theora). Despite continued and persistent assertions by bullies (backed on NOTHING but hot air), Ogg is still the best answer. Nobody claimed it is the answer, it is just a workaround. Let me be humorous for a moment. This whole discussion (which is actually NOT representative of the interests of the anti-Ogg bullies) could be summarized as: - Apple: the neighborhood punk is out to get us - Nokia: yeah - MS: indeed - (WHATWG): OK let's just not go out of our house Nobody said that, but You are free to stay at home until we come up with a better solution. For that, we need a codec that is known to not require per-unit or per-distributor licensing, that is compatible with the open source development model, that is of sufficient quality as to be usable, and that is not an additional submarine patent risk for large companies. BMP? MJPEG? WAV? You are being told this question it will take some time to answer this question. The whole point of the change was to make the point that we need something that will not screw you. Ogg isn't a solution, as it won't be implemented by Apple and Microsoft. Honestly, if Apple and Microsoft don't implement Ogg, it will *GUARANTEED* not screw me. If you put it in the spec, they will have to implement it or -- failing that -- there are simple JS-based fallback solutions that are perfectly degradable. So there is NO excuse. It depends on Web authors, and authors rely on what they can see. Otherwise everybody would be using Q for quotations by now. For the record: I don't see a conspiracy. All I see is big interests clearly colluding in the open to further restrict choice for the rest of us. For the record: col·lude –verb (used without object), -lud·ed, -lud·ing. 1. to act together through a secret understanding, esp. with evil or harmful intent. 2. to
Re: [whatwg] several messages regarding Ogg in HTML5
Dnia 11-12-2007, Wt o godzinie 23:20 +0100, alex pisze: First, I would like to thank you for the feedback, and I must admit it is a rather sensitive situation, more so then I imagined at first. But because of the nature of submarine patents, I don't quite see how you can actually find a codec that fits the requirements? You can't use an encumbered codec obviously, and the rest is up for grabs by people who misuse legislation for their own benefit? So what else is there (excepting codecs that are outdated in every way that is)? That said, my vote still lies with ogg. Perhaps a unencumbered codec exists that the big vendors would be unwilling to torpedo for some reason? The reason, of course, must be different than the codec in question is clear and safe; it must be an economical one. It would be interesting to see what would happen if the European Commission offered Microsoft a deal: some of the antitrust fine for OGG support in Internet Explorer. Chris
Re: [whatwg] several messages regarding Ogg in HTML5
I think you meant Vorbis, but other than a quick sed s/Theora/Vorbis/g, I see myself agreeing with you. El Mar 11 Dic 2007, Jeff McAdams escribió: Ian Hickson wrote: On Tue, 11 Dec 2007, Maik Merten wrote: If keeping the web free of IP licensing horrors and being interoperable with as many players as possible (commercial and non-commercial entities, open source or not, free software or not) isn't much of a reason things are looking cheerless for the web indeed. Actually those are pretty much the only reasons being taken into account here. Sadly, Ogg doesn't keep the Web free of IP licensing horrors, due to the submarine patent issue -- as Microsoft experienced with MP3 and with the Eolas patent over the past few years, for instance, even things that seem to have well-understood patent landscapes can be unexpectedly attacked by patent trolls. Then you need to stop work on a HTML5 spec right now because *EVERYTHING* has a submarine patent risk to it. Theora was developed, by all accounts, after as exhaustive of a patent search as is possible, and designed to not infringe on any patents. That's as close to being sure that you're patent free as you can get. This is the least risk option going forward. Its also the only option that I see that can hold true to the w3c's ideals of freedom (which I strongly support). Apple and Nokia's stated reasons for objecting to Theora are crap...they don't pass the smell test. Ian, you're being taken for a ride, here. Just revert the text and go back to Theora as the codec of choice and end this charade of trying to look like you're taking everyone's concerns into account because its clear that you aren't. Apple and Nokia are, so far, getting their way, despite the huge public outcry that you're seeing, and that should tell you something, and tell you something loud and clear. Apple and Nokia's reasons for objecting to Theora don't pass the smell test. Nokia even called Ogg proprietary in their white paper I've sure you've read as well. This is so badly wrong as to have become the butt of jokes. What are the real reasons that Nokia and Apple object to Theora? Clearly the reasons that they have stated are a smoke-screen because they don't even withstand the most basic of scrutiny. If you want a baseline codec that everyone supports, revert the text and then s/SHOULD/MUST/ . Apple and Nokia may not like it, but that's the only real option if you want a codec that everyone can support. And, yes, Apple and Nokia *can* support it, the risk is negligible, and technically is not hard to do. I don't exactly see why the web should embrace non-free standards just because the big players made the mistake of licensing definitely-encumbered formats and are unwilling to take further risks. (I am aware this is a pretty hard wording and that things aren't quite that easy.) In the absence of IP constraints, there are strong technical reasons to prefer H.264 over Ogg. For a company like Apple, where the MPEG-LA licensing fee cap for H.264 is easily reached, the technical reasons are very compelling. Except that there are *KNOWN* IP (god how I hate that term) constraints with H.264. At least with Theora we can avoid any known ones. All codecs have a risk of submarine patents (though with extensive having been done for Theora, at least that risk is lowered, if not eliminated completely), so that argument is a wash, its on both sides of the equation, so it cancels out. Is H.264 a better codec technically, yeah, ok, and Nokia and Apple are free to support it if they wish in addition to Theora, or even to implement all of the HTML5 spec except for Theora support and risk being called out as non-conformant. The old wording was a SHOULD requirement. No MUST. If the big players don't want to take the perceived risk (their decision) they'd still be 100% within the spec. Thus I fail to see why there was need for action. The problem is that if the big players don't follow the spec, even the SHOULD requirements, then the spec is basically pointless. What we want isn't that some people support Ogg, what we fundamentally want is that _everyone_ support the same codec, whatever that may be. Then revert the text and make it a MUST. As far as I know, there are no other codecs out there that are not encumbered. This is the whole reason for existence of Theora, at least at the time, and I don't know that this has changed in the few years since it was designed. If you want a baseline that everyone can implement without being encumbered, then the answer is Theora. Small companies aren't targetted by patent trolls. Only big (really big) companies are. It's a big-company concern, just like no per-user licensing is a small-company concern. That's just the reality of the situation, it's not intended to be a bias. Except that it very clearly is biasing the decision making process
Re: [whatwg] several messages regarding Ogg in HTML5
At 23:20 +0100 11/12/07, alex wrote: I have seen this argument pop up now and again, but I have failed to actually find the URL to this, could someone post it please? Hi. It was a record of a discussion at the HTML WG meeting, but since I wrote it, I guess I can re-post it here (and it doesn't mention names either). * * * Preamble: The HTML5 specification contains new elements to allow the embedding of audio and video, similar to the way that images have historically been embedded in HTML. In contrast to today's behavior, using object, where the behavior can vary based on both the type of the object and the browser, this allows for consistent attributes, DOM behavior, accessibility management, and so on. It also can handle the time-based nature of audio and video in a consistent way. However, interoperability at the markup level does not ensure interoperability for the user, unless there are commonly supported formats for the video and audio encodings, and the file format wrapper. For images there is no mandated format, but the widely deployed solutions (PNG, JPEG/JFIF, GIF) mean that interoperability is, in fact, achieved. Licensing: The problem is complicated by the IPR situation around audio and video coding, combined with the W3C patent policy http://www.w3.org/Consortium/Patent-Policy-20040205/. W3C seeks to issue Recommendations that can be implemented on a Royalty-Free (RF) basis. Note that much of the rest of the policy may not apply (as it concerns the specifications developed at the W3C, not those that are normatively referenced). However, it's clear that at least RF-decode is needed. Candidates: There are, of course, a number of codecs and formats that can be considered. A non-exhaustive list might include a variety of 'public' codecs, as well, of course, as proprietary ones: a) open-source projects: the ogg family (vorbis, theora), and the BBC Dirac video codec project b) Current ISO/IEC (MPEG) standard codecs, notably the MPEG-4 family: AVC (14496-10, jointly published with the ITU as H.264), AAC (part of 14496-3) c) Older MPEG codecs, notably MPEG-2 layer 3 (aka MP3), MPEG-2 layer 1 and 2 audio, and maybe MPEG-4 part 2 video (14496-2) d) Current standard codecs from other bodies; SMPTE VC-1, for example e) Older standards from other bodies: ITU recommendations H.263 (with or without its many enhancement annexes) or even H.261 f) Very old standard codecs, formats, or industry practices; notably the common format for video from digital still cameras (Motion JPEG with uncompressed audio in an AVI wrapper) g) Proprietary codecs, such as Dolby AC-3 audio Candidate concerns: There are concerns or issues with all of these: a) a number of large companies are concerned about the possible unintended entanglements of the open-source codecs; a 'deep pockets' company deploying them may be subject to risk here; b) the current MPEG codecs are currently licensed on a royalty-bearing basis; c) this is also true of the older MPEG codecs; though their age suggests examining the lifetime of the patents; d) and also SMPTE VC-1 e) H.263 and H.261 both have patent declarations at the ITU. However, it is probably worth examining the non-assert status of these, which parts of the specifications they apply to (e.g. H.263 baseline or its enhancement annexes), and the age of the patents and their potential expiry. f) This probably doesn't have significant IPR risk, as its wide deployment in systems should have exposed any risk by now; but it hardly represents competitive compression. g) Most proprietary codecs are licensed for payment, as that is the business of the companies who develop them. Other licensing concerns: It's also possible that there are other issues around licensing: a) variations in licensing depending on filed patents in various geographies b) restrictions on usage, or fees on usage, other than the fees on implementation (e.g. usage fees on content sold for remuneration). It's not entirely clear, also, whether 'implementing' HTML means the ability to decode and display, or whether encoding is also included. Including encoding in the equation might significantly complicate matters. Possible action: The members of the WG are engineers, not IPR experts. There is general consensus that a solution is desirable, but also that engineers are not well placed to find it: a) they are not experts in the IPR and licensing field; b) many of them are discouraged by their employers from reading patents or discussing IPR. It's clear that the December workshop cannot be silent on this subject. There must be recognition of the issue and evidence of at least efforts to solve it, and preferably signs of progress. It is probable that this is best handled in parallel with the technical work, and headed by someone 'technically neutral' and qualified, such as W3C technical and legal staff. A good start would be to: a)
Re: [whatwg] several messages regarding Ogg in HTML5
At 17:30 -0500 11/12/07, Jeff McAdams wrote: Apple and Nokia's stated reasons for objecting to Theora are crap... I can't speak for Nokia. But you are mis-characterizing Apple. We have expressed concern, and suggested that perhaps someone who can be seen to be independent, and is competent in IPR issues and permitted to read patents and discuss licenses, look into the issue. Folks, engineers are * not patent experts (indeed, many companies don't allow their engineers to read patents unless instructed) * not lawyers * now always seen to be independent or neutral * not generally involved in licenses This is not a recipe for progress. We'd be better off discussing technical issues that would inform a decision; questions like a) what compression ratio/quality is needed? Is h.261 'good enough'? What about audio? b) do we need alpha support? c) what audio compression level is needed? Is IMA 4:1 good enough? Could we live with uncompressed PCM? d) what container format features are needed? Incremental files? Seekability and indexing? (These tend to be in conflict, by the way). e) what audio channel count is needed? f) what access protocols should be supported? One assumes http; what about rtsp/rtp? authentication in rtsp? which rtsp? shoutcast? I am sure there are many other questions... -- David Singer Apple/QuickTime
Re: [whatwg] several messages regarding Ogg in HTML5
Dave Singer wrote: At 17:30 -0500 11/12/07, Jeff McAdams wrote: Apple and Nokia's stated reasons for objecting to Theora are crap... I can't speak for Nokia. But you are mis-characterizing Apple. We have expressed concern, and suggested that perhaps someone who can be seen to be independent, and is competent in IPR issues and permitted to read patents and discuss licenses, look into the issue. Fine, then as a show of good faith, revert the text while this goes on. Yes, I am suspicious of Apple's motives, *EXTREMELY* suspicious. As I mentioned in another email, I've never been disappointed when I assumed the worst of a big company in a standards setting context. Listen to what the people are saying. -- Jeff McAdams They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin signature.asc Description: OpenPGP digital signature
Re: [whatwg] several messages regarding Ogg in HTML5
I've tried to pick a representative sample of the e-mails sent since my last e-mail. The ones I didn't reply to have been saved to the outstanding video codec feedback folder, and I'll reply to them once we have a real solution to the problem of finding a common codec. http://www.whatwg.org/issues/#graphics-video-codec (The list is updated daily, so it doesn't yet have all the new e-mail.) I would encourage new participants to read this blog entry from Chris Double, the Mozilla engineer who implemented most of video in Firefox, as it summarises the issues nicely: http://www.bluishcoder.co.nz/2007/12/video-element-and-ogg-theora.html That said: On Tue, 11 Dec 2007, alex wrote: But because of the nature of submarine patents, I don't quite see how you can actually find a codec that fits the requirements? You can't use an encumbered codec obviously, and the rest is up for grabs by people who misuse legislation for their own benefit? So what else is there (excepting codecs that are outdated in every way that is)? That said, my vote still lies with ogg. There are several solutions we might find. For example: * We could convince the MPEG-LA group to provide a royalty free license for one of their codecs, e.g. H.264 Baseline. * We could wait for Ogg to be used by a large fraction of the Web population, as that would provide the business reason for companies like Apple to support Ogg. * We could use an codec old enough that all patents claimed to be essential to its implementation have expired. The discussions to these ends are happening. On Tue, 11 Dec 2007, Jeff McAdams wrote: Then you need to stop work on a HTML5 spec right now because *EVERYTHING* has a submarine patent risk to it. It's a matter of risk management. Some things are worth the risk, others might not be. Video codecs tend to be _extremely_ risky. Apple and Nokia's stated reasons for objecting to Theora are crap...they don't pass the smell test. Ian, you're being taken for a ride, here. To be honest at the end of the day it doesn't actually matter _why_ Apple and Nokia won't implement Ogg Theora. If they don't implement it, we don't have interoperability, and we've failed in our goal. Just revert the text and go back to Theora as the codec of choice and end this charade of trying to look like you're taking everyone's concerns into account because its clear that you aren't. Apple and Nokia are, so far, getting their way, despite the huge public outcry that you're seeing, and that should tell you something, and tell you something loud and clear. Actually, right now _nobody_ is getting their way. The spec doesn't say _what_ codec should be used. Requiring Ogg Theora support would be not taking everyone's needs into account. Right now, the spec just lists everyone's needs, without a solution. In the absence of IP constraints, there are strong technical reasons to prefer H.264 over Ogg. For a company like Apple, where the MPEG-LA licensing fee cap for H.264 is easily reached, the technical reasons are very compelling. Except that there are *KNOWN* IP (god how I hate that term) constraints with H.264. Indeed, H.264 is unacceptable as well. At least with Theora we can avoid any known ones. All codecs have a risk of submarine patents (though with extensive having been done for Theora, at least that risk is lowered, if not eliminated completely), so that argument is a wash, its on both sides of the equation, so it cancels out. Not for companies that have already taken the risk of one of the codecs already. For example, if Opera ships with Ogg Theora, then they'd probably be less interested in also supporting Dirac (another theoretically free video codec), since doing so would increase their potential patent attack surface. (Also, the smaller the company, the less the risk. Companies like Microsoft, Apple, and Google take on huge risks. Just look at Microsoft's track record recently getting sued for patent infringements, or Apple's track record of being sued over patents that the iPhone aledgedly infringes.) The problem is that if the big players don't follow the spec, even the SHOULD requirements, then the spec is basically pointless. What we want isn't that some people support Ogg, what we fundamentally want is that _everyone_ support the same codec, whatever that may be. Then revert the text and make it a MUST. As far as I know, there are no other codecs out there that are not encumbered. This is the whole reason for existence of Theora, at least at the time, and I don't know that this has changed in the few years since it was designed. There's no point putting a MUST in the spec if we _know_ that it won't be followed. We're not writing specs to satisfy a theoretical need, we're trying to get actual interoperability across all browsers. If you want a baseline that everyone can implement without
Re: [whatwg] several messages regarding Ogg in HTML5
At 2:19 + 12/12/07, Ian Hickson wrote: I would much rather Apple not implement HTML5 at all, so I can call Apple out on it in the marketplace, than to let an encumbered technology be ensconced in a standard like HTML5. I entirely agree that it would be unacceptable for HTML5 to require encumbered technology. ++ without an appropriate grant of license (I think almost all codecs have some encumbrances -- the BBC owns patents in Dirac, for example; the question is the nature of the license.) -- David Singer Apple/QuickTime
Re: [whatwg] several messages regarding Ogg in HTML5
On Dec 11, 2007 7:47 PM, Dave Singer [EMAIL PROTECTED] wrote: I am sure there are many other questions... One question might concern the value in standardizing a shell API for proprietary codecs. If there are no freely implementable solutions, maybe the spec should drop it. Personally, I think it would be pretty offensive to ship an H.264 playing application and call it standards-based or some nonsense like that. I understand that the WG is a poor place to settle legal issues with codecs. However, it's pretty poor form to endlessly handwave objections while leaving the API in the document, as if there were no target codecs. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: [whatwg] several messages regarding Ogg in HTML5
On Dec 12, 2007 11:38 AM, Dave Singer [EMAIL PROTECTED] wrote: Possible action: The members of the WG are engineers, not IPR experts. There is general consensus that a solution is desirable, but also that engineers are not well placed to find it: a) they are not experts in the IPR and licensing field; b) many of them are discouraged by their employers from reading patents or discussing IPR. It's clear that the December workshop cannot be silent on this subject. There must be recognition of the issue and evidence of at least efforts to solve it, and preferably signs of progress. It is probable that this is best handled in parallel with the technical work, and headed by someone 'technically neutral' and qualified, such as W3C technical and legal staff. A good start would be to: a) examine the declaration, licensing, and patent expiry situation for various codecs; b) contact the licensing authorities for various codecs to determine their level of interest and flexibility, and possibly invite them to the December workshop. c) analyze the open-source codecs for their risk level, and possibly seek statements from patent owners if that is deemed prudent; What was the consensus on the what to do question? I would be quite interested to get c) undertaken and see how real the submarine patent threats are. Is that a real possibility for the W3C to do (I mean: financially speaking)? Also, if there is any potential that large patent owners could make statements about the applicability of their patents to these open specifications, the let's try it! Regards, Silvia.
Re: [whatwg] several messages
On Tue, 6 Nov 2007, Geoffrey Sneddon wrote: I think it's way better to stay consistent. Especially as the feature affects the Referer (sic) header. I too think Anne is right here � there are enough things that are inconsistent in the web already. Don't add another thing that requires me to think. I'll just make mistakes. A markup language should not require me to think � it should reflect logical structure. Importantly, outwith the structure, logic dictates contextual consistency (even if that goes against being consistent with other contexts). On Tue, 6 Nov 2007, Charles wrote: This may be one of those never been done, so can never happen things, but couldn't the spec as easily support both? It seems a bit silly that stuff should have to be spelled wrong to work. On Tue, 6 Nov 2007, Darin Adler wrote: I'm really sorry to be diving into a trivial debate like this, but in our work on the Safari browser we've always treated the HTTP header field with the name Referer as the referrer header field and considered the misspelling part of the HTTP protocol, not to be propagated into other contexts. And as far as I can tell, standards other than HTTP have taken this tack too. For example, the document you can access from JavaScript has a referrer property, without the misspelling. I don't think that spelling the attribute noreferer is consistent. It should be noreferrer. Good point, I hadn't considered the DOM attribute. I'll switch to referrer. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages about a way to disable referer headers for links
On 4 Nov 2007, at 12:40, Anne van Kesteren wrote: On Sat, 03 Nov 2007 18:27:50 +0100, Krzysztof ??elechowski [EMAIL PROTECTED] wrote: Dnia 03-11-2007, sob o godzinie 08:42 +, Ian Hickson napisa??(a): Ok, I've added a rel value similar to nofollow called noreferer that does this. While we are unable correct the spelling of referer, we certainly need not duplicate it for noreferrer. There must be some end to this self-humiliation. I think it's way better to stay consistent. Especially as the feature affects the Referer (sic) header. I too think Anne is right here — there are enough things that are inconsistent in the web already. Don't add another thing that requires me to think. I'll just make mistakes. A markup language should not require me to think — it should reflect logical structure. Importantly, outwith the structure, logic dictates contextual consistency (even if that goes against being consistent with other contexts). -- Geoffrey Sneddon http://gsnedders.com/
Re: [whatwg] several messages about a way to disable referer headers for links
While we are unable correct the spelling of referer, we certainly need not duplicate it for noreferrer. There must be some end to this self-humiliation. I think it's way better to stay consistent. Especially as the feature affects the Referer (sic) header. I too think Anne is right here... This may be one of those never been done, so can never happen things, but couldn't the spec as easily support both? It seems a bit silly that stuff should have to be spelled wrong to work. -- Charles
Re: [whatwg] several messages about a way to disable referer headers for links
While we are unable correct the spelling of referer, we certainly need not duplicate it for noreferrer. There must be some end to this self-humiliation. I think it's way better to stay consistent. Especially as the feature affects the Referer (sic) header. I too think Anne is right here... This may be one of those never been done, so can never happen things, but couldn't the spec as easily support both? It seems a bit silly that stuff should have to be spelled wrong to work. I'm really sorry to be diving into a trivial debate like this, but in our work on the Safari browser we've always treated the HTTP header field with the name Referer as the referrer header field and considered the misspelling part of the HTTP protocol, not to be propagated into other contexts. And as far as I can tell, standards other than HTTP have taken this tack too. For example, the document you can access from JavaScript has a referrer property, without the misspelling. I don't think that spelling the attribute noreferer is consistent. It should be noreferrer. -- Darin
Re: [whatwg] several messages about a way to disable referer headers for links
On Sat, 3 Nov 2007, Krzysztof Żelechowski wrote: Ok, I've added a rel value similar to nofollow called noreferer that does this. While we are unable correct the spelling of referer, we certainly need not duplicate it for noreferrer. There must be some end to this self-humiliation. Cheers, Chris On Sun, 4 Nov 2007, Anne van Kesteren wrote: I think it's way better to stay consistent. Especially as the feature affects the Referer (sic) header. I think Anne's right about this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages about a way to disable referer headers for links
On Sat, 03 Nov 2007 18:27:50 +0100, Krzysztof Żelechowski [EMAIL PROTECTED] wrote: Dnia 03-11-2007, sob o godzinie 08:42 +, Ian Hickson napisał(a): Ok, I've added a rel value similar to nofollow called noreferer that does this. While we are unable correct the spelling of referer, we certainly need not duplicate it for noreferrer. There must be some end to this self-humiliation. I think it's way better to stay consistent. Especially as the feature affects the Referer (sic) header. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] several messages about the naming of the loop attributes
On 10/26/07, Ian Hickson [EMAIL PROTECTED] wrote: Bikeshed alert. On Fri, 19 Oct 2007, Michael A. Puls II wrote: Now, I am suggesting: currentLoop - playIndex || currentPlayIndex || currentPlayCountIndex I have left this one for now. I don't like index, for reasons discussed below. I see your point. It's difficult to find something without 'loop' in it that's better than currentLoop. Maybe that's a good sign. On Fri, 19 Oct 2007, Simon Pieters wrote: I don't have an opinion about naming in general, but I will note that .playIndex is consistent with select's .selectedIndex. For me this counts as a point against -- the selectedIndex identifies an item in a list, whereas here we are identifying a general period of time. -- Michael
Re: [whatwg] several messages about the naming of the loop attributes
Bikeshed alert. On Fri, 19 Oct 2007, Michael A. Puls II wrote: Maybe we should rename 'loopcount' to 'playcount'...? playcount fits better with the number of times to play the clip than loopcount does. Ok. Done. Hmm. Is the spec really ambigious? Here's an example: [...] What you're saying is that the attribute name is non-intuitive, not that the spec is ambiguous. I agree. Changed as noted above. Now, I am suggesting: loopCount - playCount currentLoop - playIndex || currentPlayIndex || currentPlayCountIndex I have left this one for now. I don't like index, for reasons discussed below. On Fri, 19 Oct 2007, Simon Pieters wrote: I don't have an opinion about naming in general, but I will note that .playIndex is consistent with select's .selectedIndex. For me this counts as a point against -- the selectedIndex identifies an item in a list, whereas here we are identifying a general period of time. On Fri, 19 Oct 2007, Dave Singer wrote: I have wondered whether it would be clearer if we called it loopFrom and loopTo, and had loopCount be the count of the *extra* plays, and loopNumber (or loopIndex) the current *extra* play. So if loopCount is 0, loopStart and loopEnd are irrelevant, and loopNumber will never exceed 0 either. I don't think loopFrom and loopTo is necessarily better than loopStart and loopEnd. On Fri, 19 Oct 2007, Randy Drielinger wrote: The terminoly we currently have is the one that's being used in the Video / Editting branch. Although they don't sound too logical, we could keep these (thus making it more consistent definition-wise) or perhaps pursue another name set from an area and adapt those. I don't favor creating a new named set to make things clear only for HTML5.0 sake. Are you ok with the new names? On Fri, 19 Oct 2007, Dave Singer wrote: yes, and clarifying that there is a straight play from start to end, and then loopCount extra plays from loopStart to loopEnd, counted by loopNumber. The same names with repeat instead of loop would also work. is that clearer, easier to explain and understand? so a loopCount of 0 means no loops, just the straight play. loopNumber 0 means we have not yet looped. I'm not sure that loopCount = 0 is clearer than playCount = 1. In fact I think people get confused over loopCount too much, however it works. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages
On Fri, 8 Jun 2007, Dave Singer wrote: Proposal: user settings that correspond to a accessibility needs. For each need, the user can choose among the following three dispositions: * favor (want): I prefer media that is adapted for this kind of accessibility. * disfavor (don't want): I prefer media that is not adapted for this kind of accessibility. * disinterest (don't care): I have no preference regarding this kind of accessibility. The initial set of user preferences for consideration in the selection of alternative media resources correspond to the following accessibility options: captions (corresponds to SMIL systemCaptions) descriptive audio (corresponds to SMIL systemAudioDesc) high contrast video high contrast audio (audio with minimal background noise, music etc., so speech is maximally intelligible) This list is not intended to be exhaustive; additional accessibility options and corresponding preferences may be considered for inclusion in the future. Herein we describe only those user preferences that are useful in the process of evaluating multiple alternative media resources for suitability. Note that these proposed preferences are not intended to exclude or supplant user preferences that may be offered by the UA to provide accessibility options according to the W3C accessibility guidelines, such as a global volume control http://www.w3.org/TR/WAI-USERAGENT/uaag10-chktable.html. This all seems reasonable, but does the spec need to mention any of this? It already allows the user agent to pick alternative media resources based on the whims of the user or the user agent. 2) Allow the UA to evaluate the suitability of content for specific accessibility needs via CSS media queries Note that the current specification of video and audio includes a mechanism for selection among multiple alternate resources http://www.whatwg.org/specs/web-apps/current-work/#location. The scope of our proposal here is to extend that mechanism to cover accessibility options. Proposal: the media attribute of the source element as described in the current working draft of Web Applications 1.0 takes a CSS media query as its value http://www.w3.org/TR/css3-mediaqueries/, which the UA will evaluate in the process of selecting an appropriate media resource for presentation. To extend the set of media features that can be queried to include accessibility preferences, we define a new media feature for each supported accessibility preference: captions descriptive-audio high-contrast-video high-contrast-audio For each of these media features the following values are defined: * The user prefers media adapted for this kind of accessibility (: want). * The user prefers media that is not adapted for this kind of accessibility (: dont-want). * The user has expressed no preference regarding this kind of accessibility (: either). For each media feature that corresponds to accessibility preferences, an expression evaluates to FALSE if and only if the user has an explicit preference (want or don't want), and the media feature has a value of want or dont-want that doesn't correspond. For all other combinations (user disinterest or a value of either), then the expression evaluates to TRUE. Example. If the user has asked for captions: want high contrast video: don't want and the video element has video ... source media=all and (captions: dont-want) ... / source media=all and (captions: either) ... / /video The second source will be selected for presentation; the second would also be selected if the media attribute were completely omitted. Once a candidate source has been selected, the UA must attempt to apply the user's accessibility preferences to its presentation, so that adaptable content is presented appropriately. This seems reasonable. I recommend implementing these with vendor-specific prefixes, and proposing them to the CSS working group. On Sat, 9 Jun 2007, Benjamin Hawkes-Lewis wrote: Three cheers for Apple for trying to tackle some of the accessibility issues around video content! :) Without trying to assess whether CSS media queries are the best approach generally, here's three particular issues I wanted to raise: [...] I agree with these comments and would recommend they be taken into account in the design of the media query features. 2. Conflict resolution The proposal does not describe how conflicts such as the following would be resolved: User specifies: captions: want high-contrast-video: want Author codes: video ... source media=all and (captions: want;high-contrast-video: dont-want) ... / source media=all and (captions: dont-want;high-contrast-video: want) ... / /video Because style rules cascade, this sort of conflict doesn't matter when media queries are applied to styles. But you can only view
Re: [whatwg] several messages about the versioning feature in the SQL API
On Fri, 5 Oct 2007, Brady Eidson wrote: I think `bool changeVersion()` has a deficient design, and the content of its description - combined with the lack of clarity around active and open transactions - makes implementing it even more dubious. First off, it is synchronous. Fixed. But I also have some confusion about the actual intention of the method. The line that is the source of most confusion - When the method is invoked, the user agent must obtain a full lock of the database (waiting for all open transactions to be closed), and then must verify that the current version of the database matches the first argument to the method. It's easy to read this line as stating that changeVersion() needs to block waiting for all nested levels of executeSql() and their callbacks to complete, which seems nonsensical. Actually that's what we want -- the method is intended for when you want to change the schema of the database. First you want to wait for all outstanding changes to be committed, and then you want the schema to be changed. On Wed, 10 Oct 2007, Brady Eidson wrote: openDatabase() is called with a database name and an expected version string. If the database has a version, and it is different than the expected version, openDatabase() fails. This makes sense. But... Otherwise, if the database version is the empty string, or if the database doesn't yet exist, or if the database exists and the version provided to the openDatabase() method is the same as the current version associated with the database, then the method must return a Database object... 1 of these 3 situations doesn't make sense. A database without a version should not be considered valid if the caller to openDatabase() expects a version. Yeah, that should have been if the expected version is the empty string. Fixed. On Thu, 11 Oct 2007, Scott Hess wrote: Actually, I don't quite understand why simply having the empty string be a version isn't sufficient. If you don't want to bother with versioning, always use the empty string (or make the parameter optional). If you do want versioning, then it's likely that you don't want the versioning to be advisory, which is what allowing the empty string to match anything does. The idea is that you might not know what the version is (say, because some rogue code changed the version to a random string), and you want to go in and fix it. You need a way in. It may be worthwhile to allow the version to be an array. Then the app could easily say Open this database, and here is the set of versions I understand. That operation could be wrapped in a helper function which runs through the open calls catching exceptions, but it seems like something reasonable to just bake into the API, because if you have database versioning, you're almost certainly going to have multiple outstanding database versions (unlike with a server-side app, you have little control over when a client executes your app). We could do that. I'm a little wary of adding arrays everywhere though. What do other people think? Is this worthwhile? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages about the versioning feature in the SQL API
On Oct 17, 2007, at 12:47 AM, Ian Hickson wrote: But I also have some confusion about the actual intention of the method. The line that is the source of most confusion - When the method is invoked, the user agent must obtain a full lock of the database (waiting for all open transactions to be closed), and then must verify that the current version of the database matches the first argument to the method. It's easy to read this line as stating that changeVersion() needs to block waiting for all nested levels of executeSql() and their callbacks to complete, which seems nonsensical. Actually that's what we want -- the method is intended for when you want to change the schema of the database. First you want to wait for all outstanding changes to be committed, and then you want the schema to be changed. I think the remaining problem is that you can't make the version change atomic with the transaction you use to actually upgrade the schema. This could be fixed by making changeVersion() open a transaction which is the current transaction during its callback, with the requirement that the version is automatically rolled back if the transaction is. Then you can do the actual schema upgrade from changeVersion()'s callback. I believe this is reasonable to implement and would make database upgrades more sound. Regards, Maciej
Re: [whatwg] several messages
On Fri, 12 Oct 2007, Anne van Kesteren wrote: I think there should be an error code for the database being full. For some platforms there's not much storage space available and knowing whether or not there's some space left is useful. So you can decide to only store the critical data for instance. Added. On Fri, 12 Oct 2007, Scott Hess wrote: My counter-argument to this is that by the time you get the database is full error, you're probably already sunk. Granted, but at least with an error code you'll know why you're sunk. :-) I think what you're really asking for, above, is a means of saying How much data can I store?, so that you can make decisions about what to store. In the limit, that's hard for the browser to guarantee, of course. I think such an API would be best kept for v2 -- let's see if people care, first. On Sun, 14 Oct 2007, Scott Hess wrote: I think this does imply an ability to delete the entire local database, which might be a reasonable API addition. Even short of this case, you could also consider the named databases as part of an app's database schema in the sense that data could be partitioned between named databases, and later the partitioning could change, implying the need to delete the now-unused databases. True. I've added deleting databases to a list of v2 feature requests, but maybe we should bring this one forward to v1. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages
On Mon, 2 Jul 2007, Robert Sayre wrote: Basically, I think offline caches should respect the Vary: HTTP header, and maybe more. Applications will need to do this right anyway, if they want to function correctly in the presence of ISP HTTP proxies (AOL, TMobile, etc), corporate firewalls, and server-side stuff like Citrix Netscalers. The spec currently requires the old cache to be used as an HTTP cache with HTTP caching semantics obeyed, when updating. On Mon, 2 Jul 2007, Robert Sayre wrote: Yes, I should have mentioned that I don't think an Offline API will be able to handle Cache-Control:private stuff better than other proxies unless it reinvents other HTTP caching mechanisms. How does this compare to what the spec says today? On Mon, 2 Jul 2007, Robert Sayre wrote: Here are some examples: http://www.djangobook.com/en/beta/chapter14/#cn125 http://webmaster.info.aol.com/vary.html http://oregonstate.edu/~hopsonro/2006/10/01/internet-explorer-fails-to-explore-internet/ http://www.somebits.com/weblog/tech/modgzipMSIECache.html So, there you have it. mod_rewrite, mod_gzip, django, and AOL are pretty popular. And IE is kinda broken. It's not clear to me what I'm supposed to do with these. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages
On Wed, 19 Sep 2007, Maciej Stachowiak wrote: Here are my thoughts on the problem of bugzilla and similar applications with open-ended URI spaces. 1) It doesn't fit well with the URI model to treat the query part of the URI specially. First, it's not in line with the web architecture principle that URIs should be treated as opaque as much as possible. Second, why treat just the query specially? Many web applications use the path to select one of a large and growing number of items. Consider events on upcoming.yahoo.com. Event IDs are exactly analogous to bugzilla bug IDs, including the fact that they are referenced all over the web outside the control of the app itself. But they are stored in the path, not the query, for instance http://upcoming.yahoo.com/event/216441/. What's so special about the query? Agreed. 2) Many offline web apps will let you [...] make changes, including not just changing existing items, but also creating new items. To do this, at minimum there needs to be an API to inject a new resource into the offline cache programatically, with the data explicitly provided. (Let's ignore the syncing problem implicit in an application with global IDs allowing offline creation of new items, and pretend that syncing when returning to online mode will solve it or that IDs will be namespaced by creating user somehow.) I think we provide features that are enough to do this now, though not in the way you really describe. 3) Offline-enabled apps with a page per resource (like bugzilla or upcoming) and which allow editing offline will need to be changed so that at least in offline mode each page can suck its relevant data from the offline database to update itself, OR manually generate an updated page to stick into the offline cache. Indeed, though we don't support the part after the OR. 4) To suck down all the items a user cares about into a local database, you need to suck down the data, but also have some way to get at the page when offline. It's not strictly necessary to pull all the pages from the server. You could alternately use the API to explicitly add an item to the offline cache, per item #2, and do a bunch of client-side work to generate and save an offline copy of each page. For that matter, each might be an identical template that just knows how to suck down the data from the net or the local database as appropriate. I think the spec allows you to get this effect, though not really in this manner. 5) Now, given 2, 3 and 4, it seems like the online and offline versions of the app must necessarily diverge a little bit, if the offline app is to offer any form of editing while offline. I don't understand what the difference between an online app and an offline app would be in this world. 6) It's potentially costly to download data mulltiple times, so if you pull the remote data into a local database, you won't also want to pull every page reflecting that data, instead you will want to generate templates client-side and insert them into the offline cache. However, it seems like a relatively small step from there to having a single fallback page to be used for all URIs that are part of the app but haven't gotten downloaded in the course of normal use. And this would be a huge optimization, since it would save the client the need to manually generate each page for a resource of interest that has not yet been visited. Indeed, that's what the spec has now. Given point #1, I think this should be based on textual prefix matching of the URI, not just dropping the query (the scheme and authority sections should be treated specially, of course, it should not be allowed to have a fallback page in someone else's security domain). This will allow matching paths and also matching only specific kinds of queries (where the first parameter is set to some specific value, say). However, to make offline and online mode diverge as little as possible, I think perhaps such fallback pages should apply only when offline. When online, the UA should go to the real page. With the prefix-based fallback page solution, I'm not sure it will be necessary to also support individual client-generated pages. That's basically what the spec has now. On Thu, 20 Sep 2007, Aaron Boodman wrote: I think having a feature where an offline page can be served for all URIs with a certain prefix makes sense. It is basically a superset of the current Gears ignoreQuery feature, and it is something that users of our API have asked about. Right. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
