Re: [whatwg] xml:space
This issue is not limited to PRE, nor is PRE the main application. There are numerous community Web sites that allow the users to submit hypertext content. You often get I italic /I B bold/B after you submit unless you use a zero-width non-joiner between them. While this is not strictly a HTML problem, allowing xml:space would allow a workaround for broken CMS. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Monday, April 28, 2008 3:29 AM To: Henri Sivonen; liorean; Anne van Kesteren; Martin Atkins Cc: whatwg Subject: Re: [whatwg] xml:space I haven't done anything with xml:space. It doesn't do anything, and it's not an HTML5 thing, so as far as I can tell it is out of scope for HTML5. On Mon, 22 Jan 2007, Henri Sivonen wrote: Since this editor artifact is harmless in browsers and useful in editors, it would be nice if the spec made it conforming at least on the pre element in XHTML5. Suggested text: The xml:space attribute may be used on XHTML elements of XML documents. Authors must not use the xml:space attribute in HTML documents. The xml:space attribute, if present, must have the literal value default or the literal value preserve. The meaning of this attribute is outside the scope of this specification. If that's too permissive, here's what would minimally cover my use case: In XHTML (but not in HTML), the element pre may have the attribute xml:space. If the attribute is present, the value of the attribute must be preserve. The first conforms to XML 1.0 for sure. The latter may not exactly, depending on spec interpretation. I don't see why we should special-case this particular harmless non-HTML feature, and not any number of other harmless non-HTML features. If another specification wants to define something, then it's up to that specification to define when it can be used. On Tue, 23 Jan 2007, Martin Atkins wrote: Presumably its primary purpose is to act as a signal to generic XML tools - that don't have any special knowledge about XHTML - that they should not screw around with the whitespace inside PRE, etc. One obvious example of such a tool is an XML pretty-printer. While an HTML pretty-printer like HTML Tidy can have rules hard-coded into it, this is not true of a non-validating XML formatter unless it is specifically written for XHTML. It seems that given the importance of XHTML, we can expect pretty printers to be written for it.
[whatwg] HTML semantics and file system
When writing technical HTML documents, I often feel a need for an element to represent a path or a file in the file system. But I couldn't find any semantically correct element to do this. I usually use em class=filesystemC:\foo\bar/em but it just feels wrong... Is it worthy to have another HTML element like filesystem (I'm not sure if this is the better name for the element) to represent a path (e.g. C:\foo\bar) or a file name (e.g. README.txt)? -- Samuel Santos http://www.samaxes.com/
Re: [whatwg] HTML semantics and file system
Samuel Santos wrote: When writing technical HTML documents, I often feel a need for an element to represent a path or a file in the file system. But I couldn't find any semantically correct element to do this. I usually use em class=filesystemC:\foo\bar/em but it just feels wrong... Is it worthy to have another HTML element like filesystem (I'm not sure if this is the better name for the element) to represent a path (e.g. C:\foo\bar) or a file name (e.g. README.txt)? The spec states (emphasis added): The code element represents a fragment of computer code. This could be an XML element name, a *filename*, a computer program, or any other string that a computer would recognise. http://www.whatwg.org/specs/web-apps/current-work/#the-code -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Footnotes, end notes, side notes
Although providing the footnote as a tool-tip seems appealing at the first glance, it is not exactly how it should be done. Footnotes are commonly used for bibliographic references; using the title attribute seems to be a non-solution in this case. Text of such footnotes cannot be copied and they cannot contain hyperlinks. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Monday, April 21, 2008 2:19 PM To: WHATWG List Subject: Re: [whatwg] Footnotes, end notes, side notes On Sun, 5 Nov 2006, Martin Atkins wrote: It seems to be that the visual continuous media equivalent of a footnote is something like a tooltip or pop-up box containing some text. It'd only be displayed when the user requests it, by clicking on or hovering over it. Paper documents permanently display the footnotes only because of the limitations of the media. Doing click-to-view footnotes with current CSS is tricky, but doing hover-to-view is reasonably straightforward using some trickery with the :hover pseudo-class and display:none, as long as the footnote content is inline. Reverting to traditional footnotes for print media based on the same markup is not straightforward, however. The CSS3 support for shuffling elements about would do it, but we're not there yet. I think the CSS stuff is less of a big deal than you make it out to be, but I agree in general with those comments. On Wed, 1 Nov 2006, Michael(tm) Smith wrote: Whatever browser implementation poverty there might be in handling of the title attribute, the fundamental deficiency is that basing a mechanism for displaying annotations on an attribute value limits the content of the annotations to text. Annotations that can't even contain simple character formatting are useless for anything except the simplest purposes. All good points. One thing to consider when looking at footnotes is would the title= attribute handle this use case as well as what I'm proposing?. If the answer is yes, or almost, then it's probably not a good idea to introduce the new feature. I really don't think so. There are accessibility and usability issues with the title attribute. * Screen readers don't read the title attribute by default. * Tooltips are inaccessible (in current implementations) to keyboard users, they require hovering with a mouse. * Users have no clear way of identifying which content has a tool tip, except for maybe abbr and acronym (which get a dotted border in FF). * It's also limited to plain text, when even the example from wikipedia contains additional markup. The first 3 issues could possibly be addressed by changing the rendering, but how do you identify a regular title attribute from one intended to be a footnote? Would it be appropriate for all of them to be treated as footnotes? I don't think so. Wouldn't it? When an author cannot got hold of a work herself, she must sometimes cite a citation of that work in second work. This is what the abbreviation cit. is for. And sometimes a citation refers to more than one version of a work. Here's an example out of the Oxford Style Guide: J. D. Denniston, /The Greek Particles/ (Oxford, 1934; citations are from the 2nd edn., 1954). Without more clarity (and that partly means examples) on how cite / should apply to the complexity of real academic citations, I'd avoid making the assumption that cite / cannot contain cite / -- for now. cite is now defined to mean title of work.
Re: [whatwg] ALT and equivalent representation
What is the advantage of cutting an image to parts and having the browser show them as one by putting them aside? I would rather use one big image in the first place. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shannon Sent: Monday, April 21, 2008 3:18 AM To: WHAT working group Cc: Bill Mason; Smylers Subject: Re: [whatwg] ALT and equivalent representation Fallback for current browsers is something I overlooked but it is easy to do: altgroup id=hippo value=Hippopotamus img src=hippo_head.png altgroup=hippo alt=Hippopotamusimg src=hippo_tail.png altgroup=hippo With the alt simply being overridden by altgroup in a HTML5 browser. Shannon
Re: [whatwg] Feeedback on dfn, abbr, and other elements related to cross-references
I am sorry to hear that cross-references are gone. The replacement you suggest does not catch the difference between navigational and informational hyperlinks. The difference is essential e.g. for GNU info: navigational links are near jumps to child nodes; informational links can transport the reader anywhere, with the way back undefined except for the browsing history stack. OTOH any hyperlink can lead into the blue (that is where the prefix hyper comes from). Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Monday, April 21, 2008 12:27 AM To: [EMAIL PROTECTED] Subject: [whatwg] Feeedback on dfn, abbr,and other elements related to cross-references HTML5 had a complex mechanism for cross-references using dfn, abbr, i, and so forth. I've removed it. It really didn't add much compared to a href= other than a whole lot of complexity, and there was very little demand for it really.
Re: [whatwg] postMessage feedback
Jeff Walden wrote: Ian Hickson wrote: I haven't changed the target of the event, it's still the Document object. This is a little odd, though, would people rather I made it the body element with an auto-forward to the Window object, like the 'load' event and so forth? That would allow onmessage= handles to be written. I've mentioned this on IRC but should probably mention it here so it's in the record, so to speak. I don't see a strong use case for an onmessage attribute. Event handler attributes are useful for quick little things, but accepting messages from other sites seems neither quick (aside from free-for-all walls I can't think of things you'd want to do that wouldn't be fairly involved) nor little (you need the origin check at a minimum, then you have to do whatever you're going to do, and it's a lot to stuff in an attribute -- and if you're just delegating to another method, why not just set the method as handler programmatically?). I don't think having to do it via script is particularly burdensome. On the other hand, if there is no particular reason why it is better for it to be on the document object, it seems sensible to me to be consistent with what already exists. (I'm not saying that there *is* no particular reason, but I don't know what it would be.)
Re: [whatwg] ALT and equivalent representation
Or even img src=11100 alt=3/5 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Mason Sent: Saturday, April 19, 2008 10:14 PM To: Simon Pieters Cc: [EMAIL PROTECTED] Subject: Re: [whatwg] ALT and equivalent representation Simon Pieters wrote: For instance it would be reasonable to use two images -- a filled star and an unfilled star -- to represent a rating of something: pRating: img src=1img src=1img src=1img src=0img src=0/p You'd want the text version to be: Rating: 3/5 There would probably be the argument for more literal interpretations (not that I would automatically subscribe to any of them as correct), such as Rating: (3 black stars in unicode) (2 white stars in unicode) Rating: *** (or 3 stars of some sort in unicode) (if the context of the page already established that ratings were on a scale of 5) Hence: pRating: img src=1 alt=3/5img src=1 altimg src=1 altimg src=0 altimg src=0 alt/p Or pRating: img src=1 alt=#9733;img src=1 alt=#9733;img src=1 alt=#9733;img src=0 alt=#9734;img src=0 alt=#9734;/p pRating: img src=1 alt=*img src=1 alt=*img src=1 alt=*img src=0 altimg src=0 alt/p -- Bill Mason Accessible Internet [EMAIL PROTECTED] http://accessibleinter.net/
Re: [whatwg] Proposal: target=_reference
Křištof Želechovski wrote: How about target=_guide instead? A reference is usually lengthy and unreadable; the designer should know better than to treat the poor user with a reference. Or _notification. Most of what Matthew wants to use it for seems to be notifications. How are you supposed to figure out the size of this thing? If it's for footnotes and TOS and errors and help and what's-this all at once.. they have different layout requirements. Footnotes fit fine at the bottom, but notifications should be at the top. Small help content could be anywhere, but extensive help content would fit better on the side, especially on wide screens. Squeezing significant amounts of text content into a top or bottom panel would make it hard to read: that space is wide and short. And TOS pages need more space than any of these if you're actually planning to read them, but they don't need to be side-by-side with the original page: in that case a floating box in the middle of the page would be ideal. Etc. ~fantasai
Re: [whatwg] ALT and equivalent representation
ALTGROUP is a dirty trick; if you insist on having the images separate, which you really should not do, you can have image alt=3/5 img src=part1.png /img src=part2.png /img src=part3.png /image This extension would be closer to the meaning IMHO. Otherwise, what happens if the images that belong to the same ALTGROUP of yours are not contiguous? Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shannon Sent: Sunday, April 20, 2008 1:30 PM To: whatwg@lists.whatwg.org Subject: Re: [whatwg] ALT and equivalent representation What about this as a possible solution? img src=part1.png altgroup=rating img src=part2.png altgroup=rating img src=part3.png altgroup=rating altgroup id=rating value=3/5 I don't think this would raise any serious implementation issues as the logic is quite simple; If all elements in an altgroup are unavailable then display the value of the altgroup tag. The alt attribute would then be optional where altgroup is defined but required in all other cases. Shannon
Re: [whatwg] text/html for html and xhtml
If the server infers the MIME type from content and sends it over HTTP as it should, you can have both. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Boris Zbarsky Sent: Saturday, April 19, 2008 6:10 AM To: William F Hammond Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [whatwg] text/html for html and xhtml William F Hammond wrote: Or, if that is too hard or too politically difficult, going forward the WG should provide a formula for the front of a document that asks for an xhtml parse. What is the benefit over using a MIME type as now, though? -Boris
Re: [whatwg] DOM Storage feedback
On Apr 27, 2008, at 5:32 PM, Ian Hickson wrote: On Thu, 10 Apr 2008, Brady Eidson wrote: In 4.10.5, the description of the properties on the StorageEvent object mentions ...its newValue attribute set to the new value of the key in question, or null if the key was removed... So a web author can assume that when handling a StorageEvent whose newValue property is null that the event was the result of a removeItem(), and the key is no longer in the list. However in 4.10.2 in the discussion of setItem(), there is no mention that null is not an allowed value. Something like sessionStorage.setItem(key, null) is not forbidden, therefore it is allowed, and it would result in a StorageEvent with a null newValue. To resolve this case, I propose that we specify that the value in a key/value pair cannot be set to null. I see two clean ways to specify this: 1 - Throw an exception when setItem() is called with a null value. 2 - Specify setItem(key, null) to have the exact same effects as removeItem(key). I prefer #2. Thoughts? On Fri, 11 Apr 2008, Anne van Kesteren wrote: Euhm, setItem() takes two strings. Therefore I'd expect null, undefined, etc. to be stringified. On Thu, 10 Apr 2008, Brady Eidson wrote: Ugh... yup. You're right. Nevermind! I'm not sure I understand why this is not an isue, but ok. I would like to make sure that my understanding is correct here, since you expressed doubt. Anne was asserting that since the interface for setItem() specifies a DOMString as the input, anything you pass it will be stringified. Therefore passing it the null value would be stringified to null. This is what you currently see in all the major browsers with window.alert(null), for example, which is also specified as a DOMString input parameter. Therefore a call to setItem(foo, null); becomes, in effect, setItem(foo, null); Is this correct? If so, the spec is fine as-is, and removeItem() is the only way to remove an individual item. ~Brady -- Ian Hickson U+1047E) \._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _ \ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'-- (,_..'`-.;.'
Re: [whatwg] Lowercase attribute values
Ian Hickson wrote: On Mon, 29 Aug 2005, Henri Sivonen wrote: On Aug 28, 2005, at 09:56, Henri Sivonen wrote: How should the lowercasing be performed? Using the locale-insensitive Unicode case data or for ASCII only treating non-ASCII as an error? On further reflection, it seems to me the latter has to be chosen at least for a parser that is intended to be used as a part of a conformance checker. Otherwise input type=RADİO ... would pass. Good point. Ok, ASCII-only it is. Can't find this in the spec atm, maybe it's on your to-do list. You need to define what case-insensitive means. For some background, you can see the relevant discussions for CSS http://www.w3.org/blog/CSS/2007/12/12/case_sensitivity ~fantasai
Re: [whatwg] ALT and equivalent representation
On Mon, Apr 28, 2008 at 2:04 PM, Křištof Želechovski [EMAIL PROTECTED] wrote: What is the advantage of cutting an image to parts and having the browser show them as one by putting them aside? I would rather use one big image in the first place. Chris On my company's web site, our header image is split into two parts. One is floated left, one is floated right, and they sit on top of a repeated background image. This lets the entire header smoothly scale to the width of the viewport. Since the two images are just pieces of a complete header image, the alt text should only show up once. I just put the alt on the first image and use alt= on the second, but it would be nice to have a canonical answer to this. Note: I am *perfectly fine* with not introducing a new element or new attributes. I feel that just putting an alt text on one of the images and leaving the others blank is sufficiently semantic. However, I do believe that this is a useful case to address in the alt text guidelines. ~TJ
Re: [whatwg] DOM Storage feedback
On Mon, 28 Apr 2008 23:14:03 +0200, Brady Eidson [EMAIL PROTECTED] wrote: I would like to make sure that my understanding is correct here, since you expressed doubt. Anne was asserting that since the interface for setItem() specifies a DOMString as the input, anything you pass it will be stringified. Therefore passing it the null value would be stringified to null. This is what you currently see in all the major browsers with window.alert(null), for example, which is also specified as a DOMString input parameter. Therefore a call to setItem(foo, null); becomes, in effect, setItem(foo, null); Is this correct? If so, the spec is fine as-is, and removeItem() is the only way to remove an individual item. This was what I was suggesting, yes. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Calling HTMLDocument.open() should change the origin of the document to the caller's origin
On Wed, 23 Jan 2008, Jeff Walden wrote: The current verbiage describing open() says nothing about the document's origin reflecting that of the mutator, which is an oversight which should eventually be corrected. This came up when considering the values of the domain/uri properties on a MessageEvent created by a document.open()ed document which calls postMessage. Just making sure this gets in the queue to be addressed... Since you can only call document.open() if you are same-origin or if both you and the victim have set document.domain to the same value, it seems that this is a non-issue. As it stands, the origin of the manufactured document will match the URI of that document as given by window.location, etc, instead of the origin of the document that created it, but that seems to be the most consistent behaviour and thus desireable. (It can't be too far from the other origin anyway, since document.domain must have been used to get from one to the other.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] text/html for html and xhtml
Křištof Želechovski wrote: If the server infers the MIME type from content and sends it over HTTP as it should, you can have both. Changing servers (including getting existing installs updated) is even more painful than changing browsers, though. It would be very nice if servers had better MIME type handling, but the reality is that they don't, and likely won't any time in the next several (5+, I would guess) years. I'd love to be proved a hopeless pessimist on this point, of course. ;) -Boris
