Re: [whatwg] Feeedback on dfn, abbr, and other elements related to cross-references
Le 2008-04-21 à 13:20, Tab Atkins Jr. a écrit : Plus, who actually wants to mark up every instance of an abbreviation? That's a ton of work for next to no reward, and apparently isn't something that can be automated (since there are conflicts between abbreviations and actual words). Mark it up once to expand it, and if you want to refer to the original abbreviation again, give it an id and link to it. Well, fully automated insertion of abbr is tricky yes, but there are ways to automate the process in a correct way. With [PHP Markdown Extra][1] for instance, you can define an abbreviation somewhere in the document and have it applied to each instance of this word through the document. Since abbreviations are defined on a per-document basis, presumably by the author, chances are they'll be all correct. [1]: http://michelf.com/projects/php-markdown/extra/ Michel Fortin [EMAIL PROTECTED] http://michelf.com/
Re: [whatwg] Footnotes, end notes, side notes
Le 2008-04-21 à 8:19, Ian Hickson a écrit : On Tue, 31 Oct 2006, Michel Fortin wrote: Interesting. If I understand well, this CSS proposal would allow a note inserted in the middle of a paragraph to become a footnote. For instance this: pThis paragraph has a footnotefootnoteThis is a footnote/ footnote./p could be presented like this (where 1 is presumably superscript and linked to the footnote): This paragraph has a footnote1. __ 1. This is a footnote. That'd very interesting. But the markup is poor for backward compatibility and makes it difficult to include more than one paragraph in a note. So I'm going to propose an improvement to this markup. (For the next example: fn = footnote; fnref = footnote reference.) What is needed to solve the backward compatibility problem is a second way of indirection, so that the footnote can be placed elsewhere. This is the first piece of the puzzle: pThis paragraph has a footnotefnref for=my-footnote/ fnref./p fn id=my-footnote pThis footnote can contain block-level elements!/p /fn In this example, a reference to the footnote is found in the paragraph, and the footnote content is elsewhere in the document. The browser would be in charge of numbering the marker correctly (or not, if the stylesheet says so) and to put the referenced footnote in a list with the other footnotes in the order they are reference. Notice the empty content of fnref? That's substitution content for backward compatibility: if you put a link to the footnote within the fnref element, when displaying things as footnote the actual content is substituted by the marker, but footnote-unaware browsers will show the link. In the previous case, the fallback content for the reference marker could have been: supa href=#my-footnote1/a/sup Since footnotes are referenced and reordered, you're free to place them wherever you want. If you care about backward compatibility, you should put them all together at the end of your article and there you have your list of footnotes. Footnotes without reference are considered to be referenced from where they are in the source. Or if you want them to be styled as sidenotes, just put the notes before or after the paragraph they relate to in the source, or even inline inside paragraphs (although inline footnotes should be restricted to inline content), and hide the marker. The last piece of the backward compatibility puzzle is the fnl (footnote list) element. This element is optional, but if present, preceding footnotes inside the same sectioning element will be relocated inside this element. fnl would be styled as an ordered list, and its list items would be footnote elements (fn). pThis paragraph has a footnotefnref for=my-footnote supa href=#my-footnote1/a/sup/fnref./p fnl fn id=my-footnote pThis footnote can contain block-level elements!/p /fn /fnl I suggest that footnotes be relocated at the end of the first article element, or to the first fnl element following them in the source. It goes without saying that footnotes already inside fnl stay where they are, although they should be reordered in the order they are referred to in the text. At this point, why not simplify the markup and remove the fnref? And turn the fnl and fn into a section and some divs or something and you have backwards compatible markup that already does everything we need without sacrificing any of the stylability... The idea of relocating the content is that one may specify in some form from a stylesheet how the notes should be rendered -- sidenotes, footnotes, endnotes would all use the same markup with a different style. (By relocating I mean it should appear somewhere else in the rendering three, not moved to another element in the DOM by the way.) The reason I came with this somewhat complex proposal is to satisfy the following cases which cannot be completely fulfilled with current markup: 1. Permitting notes as actual footnotes (not endnotes) for paged media: given some styling, the browser relocates footnotes at the end of each page. 2. Permitting notes with any content -- paragraphs, lists, code blocks (precode), etc. -- to degrade gracefully as endnotes, or sidenotes (given proper styling and placement in the source), in current browsers. 3. Permitting footnotes to be placed near the context they're referenced from when you don't care about backward compatibility (easier editing). 4. Permitting footnotes to be rendered incrementally on paged media when the content is defined before the marker (or almost-incremental if the content of a footnote immediately follows the paragraph with its marker). That said, I certainly acknowledge the argument that the feature may not be compelling enough for implementors to bother with a proposal of this complexity, and it is possible
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] My case for Ruby-elements
Le 2007-08-13 à 12:25, Křištof Želechovski a écrit : The text is not interlaced but it is vertically synchronized in order that you can know which passage in your language corresponds to which passage in the other language. HTML is unable to handle this situation except in the simple case where the text has no internal structure and can be split to passages that you can put in parallel as table data. What comes closest to my mind when reading your description is the side-by-side English French presentation of Canadian Bills, like this one: http://www2.parl.gc.ca/HousePublications/Publication.aspx? Docid=2333891file=4 I don't think Ruby markup to be appropriate here. But I can see how reading effectively such a document could be difficult on a screen reader. I'm guessing you're talking about a problem a little more complex because a table seems capable of handling that case fine (fine visually, not necessarily semantically). Do you have any example? (Preferably real-world examples.) Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] My case for Ruby-elements
Le 2007-08-12 à 14:20, Benjamin Hawkes-Lewis a écrit : This might also be an interesting use-case for the ALT element suggested on the public-html list: div class=passage p id=p4858 lang=enHello/p alt for=p4858 lang=frpSalut/p/alt /div That markup looks awfully complicated for the simple use case it's trying to solve. Wouldn't this be better: alt on=lang p lang=enHello/p p lang=frSalut/p /alt ? I've included the on attribute assuming alt would be able to define alternatives based on something other than the lang attribute, although it's not really necessary considering only the current use case. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Entity parsing
Le 2007-06-14 à 21:05, Ian Hickson a écrit : I've defined the parsing and conformance requirements in a way that matches IE. As a side-effect, this has made things like naiumlve actually conforming. I don't know if we want this. I'd make it non-conforming for the sake of readability. On the one hand, it's pragmatic (after all, why require the semicolon?), and is equivalent to not requiring quotes around attribute values. On the other, people don't want us to make the quotes optional either. I'm perfectly fine with quotes being optional; I think unquoted attribute values are generally as easy to read as their quoted counterparts, if not sometime easier since you don't have the noise of the quotes. On the other hand, it took me about a minute to figure out the word in your example -- naiumlve -- simply because I couldn't find where to put the delimitation between the end of the entity name and the last few characters in the word. In other words, is this the entity iu, ium, iuml, iumlv or iumlve ? Without a list of entities at hand, it takes a lot of guesswork to find the length it consume and the name of the entity. And not everyone can remember all those entity names. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Still more comments and questions on Web Apps 1.0
Le 2007-06-10 à 7:05, Anne van Kesteren a écrit : On Sat, 09 Jun 2007 23:03:54 +0200, Michel Fortin [EMAIL PROTECTED] wrote: I don't think XML does that, actually. See the first paragraph of http://www.w3.org/TR/xml/#syntax for the reason why this is so. White space outside the the root element is markup and not text. Yyou're right. I was indeed missing something. Thank you. In that case, I guess it'd make sense to do the same for HTML. Oh and I've said PHP 5's parser (libxml2) treat it as text; I've just realised there was an error in my test. In reality it does ignore whitespace at the root of the document. Sorry for the confusion. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Still more comments and questions on Web Apps 1.0
Le 2007-06-09 à 5:26, Anne van Kesteren a écrit : On Sat, 09 Jun 2007 04:49:56 +0200, Michel Fortin [EMAIL PROTECTED] wrote: I'd agree they're mostly useless in a browser context, but when reading HTML with the intent of reserializing it later, preserving the whitespace around the document type declaration, the comments and the root element can be beneficial for the readability of the final output. I'd keep them there, just like XML does. I don't think XML does that, actually. I've tested by dumping a tree made with PHP 5's XML parser (libxml2) before adding XML to my argument. Now, if I look at the XML spec under [2.10 Whitespace Handling][1]: An XML processor MUST always pass all characters in a document that are not markup through to the application. A validating XML processor MUST also inform the application which of these characters constitute white space appearing in element content. To me, all characters in a document also includes direct children of the document node. But perhaps I'm missing something. [1]: http://www.w3.org/TR/REC-xml/#sec-white-space Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
[whatwg] HTML5Lib Test Suite vs. PHP 5 HTML Parser
Perhaps someone will find this raw data interesting. I've made a script to run the HTML5Lib test cases against the built-in HTML parser in PHP 5. And here's the result: http://www.michelf.com/docs/html5libtests-vs-php5html.html As far as I know, PHP 5 use libxml2 as its HTML parser. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Still more comments and questions on Web Apps 1.0
Le 2007-06-08 à 21:05, Ian Hickson a écrit : 8.2.2.1. Append that character to the Document node. Having text nodes outside the root elements is at least a bit surprising if nothing else. I don't disagree. Should we just drop these spaces on the floor? It doesn't seem like the best thing but I guess I'm not opposed. What do other people think? I'd agree they're mostly useless in a browser context, but when reading HTML with the intent of reserializing it later, preserving the whitespace around the document type declaration, the comments and the root element can be beneficial for the readability of the final output. I'd keep them there, just like XML does. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] CR entities and LFCR
Le 2007-06-07 à 17:12, Michael A. Puls II a écrit : Not sure if it'll help, but whenever I do newline normalization to LF, I: Convert all CR + LF pairs to LF. Then, I convert any CRs left over to LF. Examples: LF + CR + LF + CR - LF + LF + LF. CR + CR + LF - LF + LF. I think that's the standard way of doing it. Quoting Markdown source code, and some Perl code found on Wikipedia [1]: s/(\r\n|\n|\r)/\n/g it does exactly that. [1]: http://en.wikipedia.org/wiki/Newline#Conversion_utilities Windows use CR+LF, UNIX uses LF, legacy Mac applications still use CR; but I'm not aware of any system using LF+CR (and there is none on Wikipedia) and I don't think it's useful to give a meaning to it. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Web Forms attributes: minlength / autocomplete
Le 2007-06-06 à 6:56, Sander a écrit : I'd like to see a minlength attribute that can be used on the same elements as the maxlength attribute. I'm not sure a minlength attribute like this can be consistent with maxlength. The maxlength attribute prevents users from entering more characters than the attribute's value. Should a minlength attribute prevent you from erasing characters when it would cause the value to be less characters than specified? That would be strange, if not completely useless. Also, the maxlength attribute also cause the truncation of any value set on the input. For instance, if your markup contains this: input maxlength=3 value=12345 ... it'll result in the value being truncated to 123. Should an input with minlength smaller than it's value be filled with padding characters? Before or after the value? And what happens to those characters as you type? If that's not what you want (and I'm pretty sure it's not) I don't think such an attribute, if added, should be called minlength. Perhaps requiredlength or something like that would fit better. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] No-DOM HTML
Le 2007-06-02 à 4:39, Anne van Kesteren a écrit : On Wed, 30 May 2007 15:22:39 +0200, Michel Fortin [EMAIL PROTECTED] wrote: 3) Emit events until you reach a point where it may be possible that some events should be reordered, in which case you build a local DOM-like tree and wait until you can emit all pending events with a certainty they don't need to be reordered. This is not an option. Consider bptest/p/b versus bptest/b Sending mutation events is probably the only way to go. I'm not sure I follow; what is the problem here? My suggestion was for the parser to keep a temporary tree whenever things are likely to be subject to reordering (like this case). If needed the parser just mutates its internal temporary tree. When a part of that tree are guarantied not to need reordered, then it can send SAX events for that part. The idea is effectively to *avoid* mutate events from going outside the parser since the application at the other ends, or the API in between, doesn't support them. Note that this doesn't work for parsing full documents since you can't append to the root attributes found in misplaced html tags while not keeping a tree of the whole document. But this could prove very useful for parsing HTML snippets to be included in a document server-side, just like you can do with innerHTML in the DOM. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
[whatwg] No-DOM HTML (was: noscript should be allowed in head)
Le 2007-05-30 à 8:25, Henri Sivonen a écrit : The parsing spec allows a Draconian response to parse errors. Hence, if you want SAX events, you have two conforming options: 1) Build a tree in its entirety first and then emit the events based on the tree. 2) Emit events as the parse progresses and halt on errors that require non-streamable recovery. Or, assuming the spec changes to no longer move head-elements (like link) to the head when they're found in body, there is a third option: 3) Emit events until you reach a point where it may be possible that some events should be reordered, in which case you build a local DOM- like tree and wait until you can emit all pending events with a certainty they don't need to be reordered. For instance, table requires maintaining a local DOM-like tree until the corresponding /table has been reached, at which point you know you can send events for the whole table. That's not optimal, but still better than keeping the whole DOM in memory and waiting until the end of the document to start sending events. Although it sure it more complicated too. Of course, if head-elements are sent back to the head you can't go past the head with this technique, unless you consider yourself in the innerHTML case and append them to the current node, as the spec requires. I guess this could be fine for parsing HTML snippets belonging to the body for instance. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Feedback affected by the predefined classes being gone
Le 2007-05-17 à 1:17, Ian Hickson a écrit : On Tue, 20 Feb 2007, Michel Fortin wrote: I think it'd be useful to have that on rel values (link types) as well. On Wed, 21 Feb 2007, Michel Fortin wrote: The rel attribute is about links. What I meant by that is that I think it would be useful to have a private domain for link types too. It would work a little differently than on class though, because the current spec disallows unregistered link types while it allows unregistered class names. My proposal would be to allow unregistered link types if they start with a dash -. What's the advantage of allowing this, given that authors can already use class= on links? Given that predefined classes are no longer with us (something I can't decide if it's a good thing or not), and given that this proposal was in extension of a similar one about class that no longer apply, I'm don't think it's worth pursuing anymore. The basic idea was for consistency of rel with a proposed rule for class names, and it has just fallen apart. It's true that authors can always use class. The thing is that a class name describe the nature of the content, while rel describe the nature of the link. Someone may want to use rel to be more specific, to mean that the term applies to the linked document. So, a part of my reasoning was this: if you disallow completely private values, those who want to have their own anyway will opt to use whatever they like, possibly creating conflicting values for later standards. If you allow private values at the condition that they be distinctive, such people have a future-proof way of choosing names, which gives them a reason to follow the rules and diminish the risk of conflict. In practice however, using either class or rel is going to be mostly the same. I don't have any practical example where one would be better than the other. I think, for now at least, that things are good as they are and that my porposal should be abandoned. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Predefined classes are gone
Le 2007-05-17 à 12:22, Adrienne Travis a écrit : A lot of us loved the IDEA of predefined classes, but didn't like the idea of confusing THAT mechanism with the CSS class mechanism. Personally, I really don't like thinking of class= exclusively as a mechanism to associate styles. The fact that CSS makes it easy to select on a class name doesn't mean that class names are targeted at CSS. Predefined class names made that clear, now it's less clear. While not much in favor at first, I started to like the idea of predefined class names after a while. What I like is that it doesn't try reinvent a new parallel mechanism for what class *should have been* from the start. I think the initial idea was that the class attribute would cover the the semantics while CSS the presentation of those semantics. The only problem is that earlier specs left those semantics undefined, with no way to define them unambiguously. This explains why many people, including some standard advocates, started thinking of class as a way to attach style rules of the same name to their elements (basically making class presentational). So either we fix class, or we create a new attribute (role) (and leave class as a purely presentational hook for CSS? Hurk!). The advantage of class is that it's a lot easier to use in CSS selectors, making authors more likely to use them. The advantage of role is that it begins in a clean state, which could mean less false-positive -- I'm not sure this will stay true in the long run however, especially if people see role as more semantic than class and start to use it inconsiderably... I'd tend to think there are use cases where class is most appropriate and others where it'd be better to start with a clean new attribute (role), but that's just a general feeling based on everything I've seen to date. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Predefined classes are gone
Le 2007-05-17 à 13:54, Adrienne Travis a écrit :
If we could NAMESPACE the predefined class names, that'd actually
remove ALL my objections to the idea of overloading /class/ instead of
creating a new attribute (/role/ or whatever). But unfortunately, that
totally breaks backwards-compatibility if not done very carefully. (If
i declare class=dc:author , i CAN'T address that in my stylesheet.
Well, you *can*, but it's not a pretty selector:
.dc\:author { }
or
*[class~=dc:author] { }
If the namespacing was handled with dashes, like class=dc-author,
that would work, though.)
So I suggest doing it like this:
class=-dc-author
which can be selected this way:
.-dc-author { }
The idea of the leading dash is to avoid potential clashes with
existing values: it's common today to separate two words inside a
class name with a dash, it's much less common to start a class name
with a dash. So perhaps the spec should reserve class names starting
with a dash for namespacing purpose and define the meaning of those
as the XHTML Role Module would have defined them with the semicolon
syntax.
I don't think in any way that this is incompatible with the
predefined class names that were just removed (which I liked), it's
just a little addition so you're not limited to the few predefined
ones. The XHTML Role Module also has a couple of predefined global
roles it seems.
Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/
Re: [whatwg] Predefined classes are gone
Was this supposed to be on the list? I'm not sure, so I'll reply to
you personally. Feel free to forward it if you want.
Le 2007-05-17 à 16:44, Adrienne Travis a écrit :
The CSS 1 spec says that a selector CANNOT start with a dash. I find
nothing in the CSS 2 spec to overwrite that, though i could be missing
something.
in CSS1, selectors (element names, classes and IDs) can contain only
the characters A-Z, 0-9, and Unicode characters 161-255, plus dash
(-); they cannot start with a dash or a digit; they can also contain
escaped characters and any Unicode character as a numeric code (see
next item).
Again, hard to say if it's important to have backwards-compatibility
or not, but that IS an issue.
Possibly not much of an issue however since browsers following the
specification would have to handle it anyway, if they follow the
normative grammar of the language.
With CSS 3, the grammar of the class selector is defined this way:
class
: '.' IDENT
;
In other words: a dot followed by IDENT, with IDENT defined as:
ident [-]?{nmstart}{nmchar}*
Which is: an optional dash, a start character (alphabetic +
underscore + extended unicode) followed by any character
(alphanumeric + underscore + dash + extended unicode).
In other word, a class name may not begin with a number, but, per CSS
3, it can begin with a dash. I found no other paragraph disallowing
class name selectors starting with a dash.
-- CSS 3 grammar: http://www.w3.org/TR/2005/WD-css3-
selectors-20051215/#w3cselgrammar
CSS 2.1 allows the leading dash just like CSS 3, but surprisingly
does not allow any (non-escaped) underscore in a class name.
-- CSS 2.1 grammar: http://www.w3.org/TR/CSS21/grammar.html
CSS 2 grammar does not allow the leading dash.
-- CSS 2 grammar: http://www.w3.org/TR/REC-CSS2/grammar.html
Following the formal grammar of CSS 1 is a little more complicated,
but it seems that the leading dash is allowed by the grammar, even if
disallowed by the text in the specification. (CLASS defined as
.{name} with NAME being {nmchar}+ and NMCHAR including the dash.)
-- CSS 1 grammar: http://www.w3.org/TR/REC-CSS1#appendix-b
Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/
Re: [whatwg] Sandboxing ideas
Le 2007-05-14 à 11:35, Alexey Feldgendler a écrit : I'd treat these two problems as equally important. A separate HTTP request per forum comment on the page is completely unacceptable. What about encoding the content of each comment iframe in a data: URI? Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Sandboxing ideas
Le 2007-05-14 à 16:02, Jon Barnett a écrit : On 5/14/07, Michel Fortin [EMAIL PROTECTED] wrote: Le 2007-05-14 à 11:35, Alexey Feldgendler a écrit : I'd treat these two problems as equally important. A separate HTTP request per forum comment on the page is completely unacceptable. What about encoding the content of each comment iframe in a data: URI? The contents of an iframe with a data: URI source should be trusted, unlike an iframe with an http: URI source from another domain. A script in an iframe with a data: URI source should, by default, be able to communicate with the parent window. So, that alone doesn't solve the problem. I was pointing out a solution for the problem of separate HTTP requests on a forum page. Used in conjunction with some previously- suggested security attributes on iframe, it could do a pretty good sandbox for use comments on a page. If you want the sandbox to degrade securely in older browsers, then this is not a solution. But I don't think there's a nice solution to that anyway. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Sandboxing ideas
Le 2007-05-14 à 16:19, Alexey Feldgendler a écrit : Not to mention that data: URIs are ugly, wasteful (because of the BASE64 encoding), cannot be read and written by humans directly, and have maximum length problems in some implementations. I think you can use HTTP compression to work around the inflated size of Base64, but otherwise it certainly is ugly and not human readable. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] style='' on every element
Le 2007-05-04 à 21:28, Sander Tekelenburg a écrit : I think I would agree with 1 through 3 (Michel Fortin's objects to 3, but the rationale he gives seems to only apply to 4. So I don't understand the objection to 3. But perhaps I misunderstood.) The rationale for disliking 3 (conformance checkers warning about style=) was indeed not very clear in my previous email. So let me explain my thoughts a little more. I think style= can be useful in a couple of cases. Not all style rules are reused: sometime they're used only once in the middle of a document in which case it has no real benefit and it just complicate things for the author to put the style in a separate stylesheet and work out a way to apply the style to the right element (class, id). Therefore, warning on all style attributes found in a document is a little too broad in my opinion: it's counterproductive for authors checking their documents, and it may just encourage people to blindly copy all their style rules to a stylesheet without giving in more thought. It may be a better idea for the conformance checker to parse style rules listed in the style attribute and warn only against those having a high risk of being problematic for accessibility. This later approach could have the benefit of being compatible with WYSIWYG-edited documents. In the eventuality a WYSIWYG editor was to output a style rule that compromise accessibility, I think it deserve to be flagged anyway. For instance: span style=font-style:italic could be flagged, and i proposed as a replacement. WYSIWYG editors that italicise with a style rule are most probably in the wrong anyway since whatever is meant by italics, it's likely to be relevant to the understanding of the document. p style=text-align:justify should not trigger any warning because that's the best way for a WYSIWYG editor to change the appearance of a paragraph. It's a dubious style rule for when the author is in control of the stylesheet, but it's not harmful. In other words, warn only about specific things for which you have something better to propose. Of course, nothing of this belongs in the spec. A conformance checker is free to warn about anything it wants. But systematically warning about style= is not something I would find useful. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] style='' on every element
Le 2007-05-04 à 5:53, Henri Sivonen a écrit : Considering all the above, here's my concrete proposal for a solution: 1) Make style='' a global attribute. For the purposes of document conformance, make it conforming on all documents regardless how they came to being. 2) Include an informative paragraph about how media-dependent use of style='' is bad. 3) I make the conformance checker emit a warning (at most one per document) that paraphrases the informative paragraph when the conformance checker sees a style='' attribute. 4) I make the WYSIWYG signature suppress the warning. 1, 2 good; 3, 4 bad, in my opinion. I don't think it's a good idea to create a WYSIWYG signature that changes the conformance checkers behaviour. It would create a lot of tricky cases for the WYSIWYG editor, like what to do when opening and editing a document with no signature (presumably previously edited by hand) or when editing half by hand, another half WYSIWYG, like in a split layout/code view. It's the same alike creating a Transitional version of HTML 5 reserved for WYSIWYG editors. Beside that, I'd like to point out that I, and surely many others, learned HTML from such a WYSIWYG tool, first Netscape Composer then Golive CyberStudio (before it was bought by Adobe). Only then I slowly transitioned to writing HTML by hand. What if, like I did for a long time, I edit HTML from such an application but in source mode: - How does the application decides what signature to put on the document? - What version of HTML will I learn if I hand-code in source mode? - Should the base document template be different (because of the signature) from the one of another non-WYSIWYG editor? I think forbidding, or warning against *any* usage of style= is approaching the problem the wrong way. There's no way to prevent people from using style=, and I'd say that there are some cases where style= make sense. I think it should be conforming. The new embedded style element is great, but it isn't backward compatible and is more complicated to use; style= is and is likely to be more useful for some time, despite its pitfalls. Part 2 of the solution here is spot-on: explaining the rationale for when it is wrong to use style= so that people can understand it and work around using style sheets. I think that's the way to go. 5) font is either made non-conforming or made a strictly inline element with the attribute color (to avoid span style='color: ...' cruft). Why would we need so much to avoid using the style attribute for colors? Is the cruft so big in the first case? That's about 27 characters instead of 33 for each block of text (depending on attribute quoting style and the color definition). The difference is not that big -- 6 characters for color:. Is this use case really worth its own element? span style=color:#00/span font color=#00/font | 1 2 | 3 | 4 1234567890123456789012345678901234567890 Personally, I'd be more inclined about allowing color= on any element, à la SVG, rather than having font used just for that. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Sequential List Proposal
Le 2007-04-17 à 13:05, Kristof Zelechovski a écrit : Methinks we could easily overcome the semantic problems with the dialogue element if we renamed it to transcript. The problem I described is not about the meaning of dialog, it's about structuring its content to accomodate various uses. In what way changing the name of dialog to transcript would solve the problem? I'm puzzeled. Maybe you meant changing the name would make it easier to excluse all the cases were you need to include extra information beside the speakers and the words they have said. But wouldn't not addressing the problems as a solution make the exercice pretty useless? Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] List captions
Le 2007-04-06 à 10:27, Andy Mabbett a écrit : ul captionAnimals/caption (or lh, or whatever) liCat/li liDog/li liHorse/li liCow/li /ul Personally, I can hardly see why such a markup is needed. If your list is part of the main content you should be preceding it by a header the same way you would for a paragraph. If the list is for navigation, why not simply wrap it in a nav element alongside with a header? If the list is somewhat separate of the main content, it probably belongs, with the header, in an aside element. If the list is for some illustrative purpose, a case were like a table it needs a caption, why not improve the figure element to allow lists to be put inside it? More visually, which case do you have that would not be covered by any of these markups? h1Animalsh1 ul liCat/li liDog/li liHorse/li liCow/li /ul section h1Animalsh1 ul liCat/li liDog/li liHorse/li liCow/li /ul /section nav h1Animalsh1 ul liCat/li !-- assuming you have some links here -- liDog/li liHorse/li liCow/li /ul /nav aside h1Animalsh1 ul liCat/li liDog/li liHorse/li liCow/li /ul /aside figure legendAnimals/legend ul liCat/li liDog/li liHorse/li liCow/li /ul /figure I believe the markup should depend on what your list stands for. A list is not much unlike a paragraph: it's an enumeration formatted in a special way. So why can't we reuse the already existing structures? Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
[whatwg] Sequential List Proposal
Following the discussion about the limitations of dialog, I meditated about it a little and came up with the idea to generalize things a little more. When we have a dialog intermixed with actions and other events (like ABC leaves the chat room), basically we have a sequential list of events, actions and spoken parts. And in my later example, the Canadian Parliament hansard, they're intermixed with timestamps at regular intervals and other notes regarding live translations. Again, this fits very well the concept of a list of different kinds of intermixed sequential events. So I propose a sl element (sequential list) which can be used to replace dialog as well as other things. The proposal can be found here: http://www.michelf.com/documents/whatwg/timeline/ Basically, dt and dd work just like they do in dialog currently, except that you can have more than one dd following a dt. li is used for listing events other than speech and time is used to insert time marks where appropriate. And you don't need to have any spoken part, meaning you can use it for system logs, or historical timelines too by using only li and time. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Sequential List Proposal
Le 2007-04-05 à 10:36, Simon Pieters a écrit : I get a 404 for this URI. Oops... sorry. http://www.michelf.com/documents/whatwg/sequential-list/ Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] on codecs in a 'video' tag.
Le 2007-03-30 à 16:41, Maciej Stachowiak a écrit : I think achieving broader interoperability will require us to find ways around this impasse, rather than bludgeoning each other until one side caves. Isn't Theora already more interoperable than anything else? I mean, there is a plugin for QuickTime, and there is also a filter for DirectShow allowing it to work with Windows Media Player. Linux distributions usually support Theora out of the box and anyone is reasonably free to implement the codec and distribute it as they like. I mean, it may not be the easiest format to read (need for plugins), but it certainly is the one you can read everywhere. I think that's a good reason for Theora to stay the preferred codec where interoperability is concerned. Maybe the requirement could be changed like that: User agents SHOULD support Ogg Theora video and Ogg Vorbis audio, as well as the Ogg container format. Or, alternatively, user agents SHOULD give users the means to add support for this format. That way, Theora and Vorbis can stay the preferred format, users of Apple products can rely on add-ons to read Theora content, and Apple can stay spec-compliant without having to fear submarine patents. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
[whatwg] Tendious use cases for dialog
Here are some various potential use cases for dialog I've collected and which I think are problematic with the way the dialog element is currently defined. Regular dialogue: http://www.newyorker.com/humor/2007/03/26/070326sh_shouts_rich IRC Logs: http://www.linode.com/irc/logs/linode-xenbeta.log-2006-03-26 Screenplay (not a dialogue in itself, but contains a couple of them): http://www.lynchnet.com/mdrive/mdscript.html - - - Adding specific elements for all these use cases is probably not going to be a good idea since there are too many of them. But I think allowing regular paragraphs in the content of dialog would be useful in a couple of cases. This is an excerpt from the first linked page formatted this way: dialog dtFRIEND FROM WORK:/dt ddI am the loudest! I am the loudest!/dd p(Everybody laughs.)/p dtMOM:/dt ddI had a lot of wine, and now I’m crazy!/dd /dialog Formatted excerpt from second link (an IRC log): dialog ptime21:57/time/p dtcaker/dt ddsweet/dd ptime21:57/time/p dtcaker/dt ddit worked/dd ptime21:57/time/p p class=actioncaker closes out last bug/p ptime22:04/time/p dtencode/dt ddyay!/dd dialog These to examples are non-conformant according to the current spec. I won't say this is the ideal markup, but I think it's still better than opening and closing a dialog element each time you need a p element. Any better way to markup these? Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Embedding Elements Should be Structured Inline-Level
Le 2007-03-14 à 1:23, Lachlan Hunt a écrit : Hi, The spec currently defines most embedding elements (img, iframe, embed, object, video and canvas) as strictly inline level and thus only allows them to be used in contexts where strictly inline level content may be used. I think these elements should be defined as structured inline-level elements. When used in block level contexts, they should represent paragraphs. You're right that it's often a little silly to have an image alone in its own paragraph. But maybe we could use figure for these cases: figure img /figure Ok, this is not conformant with the current spec since it's missing a legend, but in my opinion it should be allowed. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] One label: multiple fields
Le 2007-03-13 à 13:37, Elliotte Harold a écrit : Homework 1 Homework 2 Homework 3 John Smith87 86 98 Jane Jones 100 78 98 Fred Wilde89 65 69 My opinion is that the table itself, given headers are properly marked up with th, provides enough information to make the labels unnecessary. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
[whatwg] Private class names (was several messages about HTML5)
Le 2007-02-21 à 4:41, Gervase Markham a écrit : Surely it would make much more sense to have all the predefined class names start with a dash? After all, XHTML5 is not yet standardised, whereas people have been using all sorts of random class names for years - but, I suspect, mostly without a leading dash. You're proposing something that looks like the path of less resistance for adoption of the spec. While this is certainly worth something, it also happen to be the path of less intensive to use the predefined class names, or to register new ones when you need one, since private-domain class names would be prettier and easier to type than the standardised ones. Beside, it would also make it impossible to register class names currently in use by microformats. Because of all that, I think it makes more sense that the private domain be the one that starts with a dash. There is also the benefit that you can create a similar private domain for link types (for the rel attribute). By the way I know the current predefined class model is lacking in certain areas, most notably it makes clashes inevitable (although how much this is a problem is still open for debate). It could certainly be scrapped altogether in the future, but in the meanwhile I want to improve it little by little. Maybe with enough incremental improvements like this one it'll become good enough for a majority of people. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] several messages about HTML5
Le 2007-02-21 à 11:34, David Latapie a écrit : I think it'd be useful to have that on rel values (link types) as well. rel=microformat? The rel attribute is about links. What I meant by that is that I think it would be useful to have a private domain for link types too. It would work a little differently than on class though, because the current spec disallows unregistered link types while it allows unregistered class names. My proposal would be to allow unregistered link types if they start with a dash -. http://www.whatwg.org/specs/web-apps/current-work/#linkTypes - - - By the way, it would certainly be more coherent if unregistered class names were disallowed too (unless they start with a dash), but that would also make countless documents non-conformant with HTML5 so I'm not sure it's a so good idea. I can't say I dislike the idea though. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] several messages about HTML5
Le 2007-02-20 à 19:05, Ian Hickson a écrit : The proposal to have predefined class names is still very much in the air, we're mostly waiting for author and implementation feedback to see if it is workable. Currently the HTML5 spec leaves a number of things unanswered (like what happens if two classes on an element are contradictory), so it's definitely not finished. About that, I would like to suggest that the current text be changed to reserve class names starting with a dash - for private use. That way that we would have a pool of class names which are guarantied to not be taken over later when new predefined class names are added. It could even encourage some kind of namespacing for class names, in a similar way that CSS extensions -- or not yet standardised features -- are prefixed by the engine name like in -moz-border-radius or - webkit-column-count. I think it'd be useful to have that on rel values (link types) as well. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Heading, binding, LH (was:XSLT: HTML 5 -- HTML)
Le 2007-02-13 à 8:07, David Latapie a écrit : This is my belief there is a need for properly “binding” (is that the right term) a picture and description. I'd go further by saying we need the rethink the “master-slave”/“content-description” relationship in X/HTML table+caption image+description (not speaking of alt here) dt+dd list+introduction to the list (LH) table+caption works fine already. Image+description should be covered by figure, although its current restrictions are pretty limitative in my opinion. dt+dd works fine too, I think. It may be used as a substitute for figure currently, but I think the appearance of figure in the spec will make this practice obsolete. As for lists, maybe legend should be allowed within list elements, although I can't say I have seen as much interest for this as for captioning images. So I wonder what is to rethink exactly, because beside some minor issues it seems to be evolving in the right direction. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] De-emphasis
As another general comment on this discussion, I will say that I agree with David Walbert's observations that it is impossible to to de-emphasize something. However, I believe that what some means here by de-emphasising something is that they want to *emphasize the unimportance* of what they're saying. To me, de-emphasis is just another kind of emphasis where you state that the reader doesn't really need to know that thing but the author want to say it anyway. Like David, I think the best rendering for de-emphasis would be to use parenthesis, notes, or asides depending on the exact nature of the content. Frankly, I don't think we need to introduce any new element for the general case of emphasizing the pointlessness of something. If an element is introduced however, maybe pointless would be a better name, less abstract and harder to misuse than anything derived from de-emphasis. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] De-emphasis
Le 2007-02-09 à 14:21, Jonathan Worent a écrit : That was brought but a as secondary argument (still a valid point IMHO). My original use case was for transcribing dialog. This was something I was trying to do when I originally purposed it back in Aug. 07. Can I suggest a whisper element then (or something similar)? I'm still not convinced that it is needed or that it can have a good default rendering, but it'd certainly be more to-the-point than the abstract concept of de-emphasis which can be stretched to dozens of unrelated use-cases. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] The m element
Le 2007-02-09 à 16:36, Lachlan Hunt a écrit : No, the use cases for m are clear, and it is different from both em and strong. I think it should be kept as-is, though its definition in the spec clearly needs to be improved. Suggestion of an improvement to the spec: The m element represents a run of text marked or highlighted for reference purposes. I think adding for reference purposes to the current definition helps distinguish it from importance (given by strong) or stress emphasis (given by em). em : stress emphasis (changes the meaning) strong : importance (no change in meaning) m : reference marker (no change in meaning or importance) Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Fwd: Re: Heading, binding, LH (was:XSLT: HTML 5 -- HTML)
Le 2007-02-09 à 12:32, David Latapie a écrit : On Fri, 9 Feb 2007 11:40:32 -0500, Michel Fortin wrote: That was my idea of what you were doing. With this syntax there's no association between the description and the image, I'm not sure you caught that from my explanation though. I did not. And I still don't get it. A dd shall (must?) be attached to a dt A dt shall (must?) be attached to a dd There is only one of each, so they shall be attached, in my mind. What is wrong in my thinking As Anne pointed out earlier, HTML4 says this: Definition lists vary only slightly from other types of lists in that list items consist of two parts: a term and a description. http://www.w3.org/TR/html401/struct/lists.html#h-10.3 Although not clearly stated in the HTML4 spec, it's pretty certain that the two parts (term and description) were meant to appear in this particular order within a definition list because you cannot formalize the term/description association if you allow dt and dd to appear in any order. The WHATWG spec formalises term/description groups as I said -- starting with a dd or ending with a dt is non-conformant. But the new spec certainly could be more explicit about what happens to non- conformant lists starting with dd or ending with dt. http://www.whatwg.org/specs/web-apps/current-work/#the-dl With the current state of the figure element, you can't do this. I remember proposing a while ago that figure accepts more than a single embedded elements. That seem to be a good use-case. figure img ... img ... img ... legend.../legend /figure So, if figure doesn't allow this, how can it be done? With present specs and with future specs? (of course, I'm not talking of rendering but of semantics there) By improving the current spec, by going back to what you were using with HTML4, or by ignoring the spec and doing it anyway. I'm advocating the former. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
[whatwg] p in dialog
I read this text recently: http://daringfireball.net/2006/12/ apple_universal_conjectural_transcript and wondered how it could be marked up using dialog. Basically, it's a fictional dialogue between two persons where once in a while the dialogue is interrupted by actions in separate paragraphs. It looks much like a scene in a screenplay. The current spec only allows dt and dd inside dialog, so the markup for something like this would require closing dialog each time an action paragraph is added and reopening it afterward. Wouldn't it make more sense to allow regular paragraphs in dialog for situational information and action descriptions? Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Semantic styling languages in the guise of HTML attributes.
Le 20 déc. 2006 à 6:57, Matthew Raymond a écrit : A presentational markup language would be like SVG or X3D. They use markup to create a presentation that may or may not be meaningful. Huh, what is a meaningful presentation exactly? To me, what is meaningful content is *not* presentational. The presentation is the way you arrange and surround your content to make it attractive (or not). Your definition of SVG as presentational precludes it from being meaningful, although you specifically say it can be meaningful too so I'm a little confused. SVG is simply an image description markup language, just like HTML is a document description markup language. SVG being presentational depends on how it is used. SVG may be suitable for visual media mostly, that doesn't automatically make it presentational. And just like HTML, you can, to a degree, separate the meaningful parts from the presentational parts in an SVG image: if a color was chosen for presentational reasons, set it using CSS; if the chosen font for a block of text is not meaningful to the document, set it with CSS or just inherit it from the HTML document if you have inline SVG. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Semantic styling languages in the guise of HTML attributes.
Le 20 déc. 2006 à 10:23, Henri Sivonen a écrit : Actually, structure is communicated to people using presentation. Presentation isn't just about attractiveness. Point taken. It's about making the document understandable, readable, *and* attractive. I think eschewing presentational features as a matter of principle misses the point. I totally agree. HTML should be describing documents in a useful manner. Minimizing presentational features is a good idea as long as it does not reduce the capabilities of the language to correctly describe the content in a usable manner. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] finding a number...
Le 13 déc. 2006 à 6:14, Thomas Broyer a écrit : Note that the meter description reads (as an Authoring requirements !!!): The recommended way of giving the value is to include it as contents of the element, either as two numbers (the higher number represents the maximum, the other number the current value), or as a percentage or similar (using one of the characters such as %), or as a fraction. And the progress description reads: Instead of using the attributes, authors are recommended to simply include the current value and the maximum value inline as text inside the element. I find this recommendation misguided too. In fact, it should say the contrary: it should say that it is recommended to also put the numbers in attributes for non-english documents because the parser is only capable to handle the english format. That may sound a little dumb, but that's because it is, and I fully support making the attributes mandatory. At the very least, I think find-a-number should be limited to integer numbers. But even then it'll be limited to languages using our western digits and possibly not suitable for full internationalization. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] microformats incompatible with WebApps 1.0 ?
Le 11 déc. 2006 à 21:25, Ian Hickson a écrit : On Mon, 11 Dec 2006, Michel Fortin wrote: div profile=http://microformats.org/wiki/hcard-profile; class=vcard a class=url fn href=http://tantek.com/;Tantek Çelik/a div class=orgTechnorati/div /div Given that nobody does the former, why would anyone do the latter? Bear in mind that to all intents and purposes, the page looks and works exactly the same with or without the profile. Also bear in mind that enough content exists that doesn't use the profile= attribute that implementations will always look for content regardless of its presence. The only reason this is supported in my proposal is for when people want to define their own extension without having to register it with anyone. If someone wish to have a short name, it has to be registered. Obviously, hCard will have a short name, so there is little reason to use the long form. div profile=hcard a class=url fn href=http://tantek.com/;Tantek Çelik/a div class=orgTechnorati/div /div How is that? It's one step away from: div class=vcard a class=url fn href=http://tantek.com/;Tantek Çelik/a div class=orgTechnorati/div /div ...which would work just as well, and has the added advantage that it is compatible with how hCard is used today. I'm not arguing that everyone would need to change hCard on their website once HTML5 becomes a recommendation. hCard is already deployed as it is and tools still need to support that syntax. But for the future, using a profile attribute instead would ensure that existing documents do not become non-conformant the day a new extension is added. What's different is that you have to care about conformance only to the profile you're using, and no other. When new profiles are created, adding new classes and link types, you know they won't bother you. Except that in practice they will, because if suddenly your class name clashes with a new class name, regardless of whether we have profile or not, processors looking for that class name will start treating yours as one of theirs. And that's exacly the problem I'm trying to solve by making the profile attribute easier to use. It's probably true that parsers will have to continue to work with what's currently out there, but I'd like this problem to be avoided for future microformats. And as you noted, the profile attribute I illustrated above is only one step away from current practices. That's deliberate as it would make adoption and understanding easier, at least for future formats and possibly for new versions of currents formats too. I'd like to add that the same problem can exists in reverse too: there is always the possibility that someone influent, through the deployment of software or by other means, carelessly popularize a class also in use by a microformat. This would make the microformat unusable on the web. The more microformats there are, the bigger are the risks that this happen. With a separate profile attribute as defined in my previous post, this can hardly happen without deliberately violating the registration process. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] microformats incompatible with WebApps 1.0 ?
Le 11 déc. 2006 à 20:37, Ian Hickson a écrit : On Mon, 11 Dec 2006, Michel Fortin wrote: I think we should keep both systems. Things worth registering in the global namespace because they're common and not very likely to be misused (like class names currently listed in the spec: example, issue, note, warning, error, search, copyright), could be registered globally, things which are more specialized would be registered more restrictively under a profile. But we know that profile doesn't work. Maybe we could arrange profiles so that they work better instead of scraping the concept altogether. Suggestion: we could allow the profile attribute on any element? The profile would apply only to the concerned element and its descendants. So this: head profile=http://microformats.org/wiki/hcard-profile; ... div class=vcard a class=url fn href=http://tantek.com/;Tantek Çelik/a div class=orgTechnorati/div /div could become this: div profile=http://microformats.org/wiki/hcard-profile; class=vcard a class=url fn href=http://tantek.com/;Tantek Çelik/a div class=orgTechnorati/div /div That would solve the problem of having the profile far away from the actual data, which makes it difficult to copy paste and harder to see the link. In addition, we could maintain a global registry of short names for profiles, so that we could write this as a shortcut: div profile=hcard class=vcard a class=url fn href=http://tantek.com/;Tantek Çelik/a div class=orgTechnorati/div /div And since profiles can now be applied on individual elements, there's no real need to keep the redundant vcard class name since it could easily be implied by the profile being specified on that element: div profile=hcard a class=url fn href=http://tantek.com/;Tantek Çelik/a div class=orgTechnorati/div /div How is that? What worries me most about the Wiki idea is that it'll make conformance to HTML5 a moving target that would need to be reevaluated each time a new class is added on the Wiki. How is this different from conformance to HTML5 + profile-specified extensions? What's different is that you have to care about conformance only to the profile you're using, and no other. When new profiles are created, adding new classes and link types, you know they won't bother you. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] microformats incompatible with WebApps 1.0 ?
Le 11 déc. 2006 à 22:57, Mike Schinkel a écrit : But since the class is a scare resource (or profile, or whatever) that approach will result in conflicting microformats. Just a little clarification about my previous proposal. I suggested that profiles could register a short name as equivalent to a longer URL-named profile, but it wasn't intended that profile URLs be disallowed. This: div profile=http://microformats.org/wiki/hcard-profile; and this: div profile=hcard would be both allowed and equivalent, only the later is shorter to write. Private vocabularies (to not call them microformats) would be able to use URLs, but to use short names the URL would need to be registered with that name first. Any unregistered short name would be non-conformant. So profile, contrary to class, would have no possibility of conflict. (Short names would be defined as containing no colon, so that they can't be valid absolute URLs.) Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Inline SVG
Le 9 déc. 2006 à 7:32, Martin Atkins a écrit :
Using script has the ultimate advantage that existing browsers
will *already* ignore it, while for some new element legacy
browsers will attempt to parse the contents as HTML and may end up
displaying something unintended. It's unclear how you'd implement
fallback behavior for script type=application/xml, though,
since the only fallback for script is noscript, which is
ignored if the browser supports scripting of any kind, regardless
of type.
You'd need a JavaScript fallback in addition to noscript, something
like this:
script type=text/xml id=a
xml-element/
/script
noscript id=b
fallback content
/noscript
script type=text/javascript
if (/* browser does not support XML scripts */) {
if (/* has some javascript XML parser library */) {
parserLibrary.parseAndInsertXML(getElementById(a).textContent);
} else {
document.write(getElementById(b).textContent);
}
}
/script
It could also be an external script that justs search the document
for a particular class of noscript element once the document is
loaded.
This also raises an interesting question about how you'd embed an
XML application that itself features a script element, since any
/script ends the parsing of the script element regardless of
nesting. (The HTML parser just sees the XML as an opaque block of
text.)
You'd have to play with namespace prefixes:
script type=text/xml
my:script my:xmlns=...
/my:script
/script
Not the a very elegant solution however, and not very copy-paste
friendly.
Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/
Re: [whatwg] Common Subset
Le 9 déc. 2006 à 7:50, Lachlan Hunt a écrit : Alexey Feldgendler wrote: The HTML5 spec could somehow officially bless CDATA only when used like this: script//![CDATA[ ... //]]/script It would not harm because it is already interoperable. It's technically already allowed because script and style elements are defined to contain CDATA. So basically any string of text that doesn't include '/' before the end tag is valid. It's already interoperable because that whole string is passed to the javascript engine, and since the '![CDATA[' and ']]' are commented out with javascript comments, they're ignored. I added this example on the wiki page about the common subset: script type=text/javascript /* ![CDATA[ */ if (a 0 a 10) alert(A not in range (0 a 10).) /* ]] */ /script I used /* */ for comments instead of // so that the trick can work with style too, and I think the extra spaces make clearer the relationship between the CDATA block and the script. http://wiki.whatwg.org/wiki/Common_Subset Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Inline SVG
Le 8 déc. 2006 à 10:29, Leons Petrazickis a écrit : How about this for HTML5: object type=image/svg+xml svg version=1.1 xmlns=http://www.w3.org/2000/svg; circle cx=100 cy=50 r=40 stroke=black stroke-width=2 fill=red/ /svg /object Change object for script and you have my previous proposal which would probably work better. http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006- December/008444.html Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Inline SVG
Le 8 déc. 2006 à 15:20, Leons Petrazickis a écrit : http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006- December/008444.html Unlike Michel Fortin's proposal for script type=image/svg+xml/script, I suggest that SVG included like this be rendered as an image in that exact spot. We may want to define a default height and width for all inline-xml.../inline-xml content. Well, my idea was that the XML content inside script type=some xml media type would be parsed then inserted into the DOM right after the script element. In the case of SVG content, that would make the image appear exactly where the script tag is. The XML script should be seen in exactly the same way as some previous JavaScript that was shown to build a SVG WHATWG logo, only the script would use an XML syntax instead of JavaScript. In case of any parse error, the XML script aborts and you get a partial XML tree in the DOM plus an error on the script console. I'm not against using a different tag name, but I don't really see the point either. script is already parsed as text content by current browsers, so for current browsers that can't execute the script, it would be possible for an external JavaScript to parse the content, build, and insert the new elements into the DOM. What worries me most is what IE is going to do with it, because it's identical to one of the documented syntaxes for its XML islands. It's possible that it just work however. I guess someone should test that. (It's not very practical for me to check things with IE.) Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Common Subset
Replying to myself... Le 8 déc. 2006 à 8:48, Michel Fortin a écrit : noscript and document.write() workaround: create nodes programatically and avoid the use of noscript. Another noteworthy problem with the common subset about scripting is that it's really impractical to write some idioms. You can't have any instance of or in a script without throwing the document outside of the common subset: HTML requires them to be unencoded, XHTML requires them to be in a CDATA section or escaped as lt; and amp;. The CDATA solution would probably work in HTML, although it'd make the document non-conforming. This applies to inline style too. It does not apply to external scripts and stylesheets. (Note: I'm not asking that any of this be resolved, I just think that it's noteworthy.) I've added this to the wiki page about the common subset: http://wiki.whatwg.org/wiki/Common_Subset Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] several messages about XML syntax and HTML5
Le 5 déc. 2006 à 17:03, Ian Hickson a écrit : The one target now is HTML5. I wonder about one thing though. If the recommended serialization is HTML5, why is there new features which are simply not supported by HTML5 (list inside paragraphs, nested forms, etc.)? My impression is that while HTML is recommended in the prose, the new features are implicitly recommending XHTML. Recommending using the HTML format while making XHTML more powerful at the same time just strike me as incoherent. This makes it look like XHTML is the future and that HTML is a temporary and limited recommendation to keep backward compatibility. That's what I understand while reading the spec as a whole. If that's not what is intended, then maybe something should be done about that, like removing some of the incompatible features. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] PaceEntryMediatype
Le 3 déc. 2006 à 18:49, Ian Hickson a écrit : On Sun, 3 Dec 2006, Thomas Broyer wrote: What I mean is that being syndication feed is not a property of a relationship, it's a property of one end of the relationship (the resource the link starts from or points to); so it has nothing to do with the rel= attribute. I agree, in principle. Unfortunately, for autodiscovery we have to have a mechanism that can advertise what the syndaication feeds are without requiring the UA to fetch every link, because fetching every link would be much slower (and on some networks, fiscally more expensive). I'd like to suggest a possible solution that would address these two issues at the same time. The type attributes allows for parameters after the mime type. So what about this: link rel=alternate type=application/atom+xml;role=feed src=... link rel=alternate type=application/atom+xml;role=entry src=... link rel=alternate type=application/atom+xml;role=edit src=... If the type parameter role is not present, role=feed would be implied. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Authoring tools (was Graceful Degradation and MimeTypes)
Le 4 déc. 2006 à 6:14, Mike Schinkel a écrit : It does matter. It is not just one of the important things, it is THE important thing. Having two divergent HTMLs will create problems for a vast number of people and will significantly reduce efficiencies for anyone that has to deal with it. Worse, it could cause the non-technical public to decide that HTML its just too much trouble, and THAT would be a tragedy. I would tend to think that people would say well-formed XHTML is too much trouble, not HTML or pseudo-XHTML served with text/html. But that's not really better. The irony is I'm not proposing much; just have as a design axiom that the trajectory of HTML5 and XHTML should aimed toward convergence when technically possible. I don't like the word convergence as you use it: because we cannot change how HTML or XML is parsed there cannot be any real convergence. All we can do is decide what is valid and what is not within HTML, and to some extend within XHTML, and thus decide what is valid and what is not within the common subset at the intersection of the two. I don't see the use of the common subset as convergence, but as a way to avoid reimplementing the wheel to have two different outputs where it would be not necessary to do so. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] several messages about XML syntax and HTML5
Le 4 déc. 2006 à 2:55, Ian Hickson a écrit : I've been having a lot of trouble following this discussion, because I can't work out what it is that is being asked for. There seem to be multiple discussions going on, and it isn't clear to me that everybody really knows what they are arguing for or against. This discussion is pretty confusing indeed. I've changed the spec to allow a (meaningless) xmlns attribute on the root html element, for the same reasons / is allowed on void elements now. I don't think it's a particularly useful thing, but I'm curious to see what people think. (Like anything in the spec, we might remove it in due course, based on real world experiences with the spec.) I think that'll be useful. Well, SVG itself would arguably be bad because it is poor from a semantic standpoint. HTML is poor from a semantic standpoint. HTML is actually pretty rich, all things considered. SVG, on the other hand, is media-specific and presentational. div and span are poor from a semantic standpoint. They're still useful for a variety of reasons and I see no one arguing they should be excluded. I'm not saying SVG should or should not be added to HTML, but I'm pretty sure inline SVG is useful too. On Sat, 2 Dec 2006, Mike Schinkel wrote: But please take into consideration that almost nobody writes web pages using a DOM; they write web pages using text editors and dynamically using string concatonation. As such there is great value for users in having them be as similar as possible. If they converge, it will accelerate chaos on the web. With the addition of xmlns= (see above), they are now as close as possible, I believe. That's probably all that can be done on the HTML side. But would something bad happen if you were to make html:lang valid within XHTML? On Sat, 2 Dec 2006, Elliotte Harold wrote: What I don't understand is why some members of this working group is so dead set on actively preventing HTML from being XML. The non- draconian error handling I understand. But why are you disappointed that ! DOCTYPE html is well-formed XML? Why the active hostility to well- formedness? I was initially disappointed that !DOCTYPE html is well-formed because I though that it'd allow to differentiate HTML from XHTML documents unambiguously (since XHTML documents couldn't have it). That said, now I think it's probably irrelevant. The two format are not the same, but many people have been trying to find common ground since XHTML has been invented for various reasons. The result is a lot of HTML documents which are wrongly identified as XHTML (because they're not even well-formed XML). So I think dropping the HTML/XHTML identification string altogether is the right thing to do; it's meaningless anyway because a lot of authors are careless. Let's use the media type instead, the real thing browsers use to differentiate the two, and force people to make things well formed if they want it called XHTML by the validator. What I'm hostile towards is the fiction that you can take an XML parser and attempt to parse an HTML document. The two formats aren't the same, using the wrong parser is simply that, wrong. I don't think many people really think this. I think those who say that say that because they've been using some subset of HTML which is compatible with XML for their own documents, therefore *their* HTML documents can be sent through an XML parser. But I'm pretty sure people on this list realise that this doesn't apply to the general case. http://wiki.whatwg.org/wiki/ HTML_vs._XHTML#Differences_Between_HTML_and_XHTML Nice resource. That could be prove very handy. The other half could be addressed by one little box in the corner of Firefox's status bar that's a smiley face if the page is valid, and a frown if it isn't. A browser that shipped with a frowy face showing on 93% of pages would do very badly in usability studies (and thus very badly in the market). I just want to point out in case someone is interested that there is actually a browser like this for the Mac: iCab [1]. [1]: http://icab.de/ In the Web Apps 1.0 world, an HTTP message whose headers say text/ html is an HTML document, regardless of what sequence of bytes the body of the message actually say. An HTTP message whose headers say text/xml, or use some other XML MIME type, is an XML document. It's the MIME type that decides how it is processed. If it is processed as an HTML document, then it _is_ an HTML document, possibly with errors. So says the spec. I just want to say I like very much this definition. On Sat, 2 Dec 2006, Michel Fortin wrote: Having two markups pose the same problem as having two incompatible HD DVD formats. Browsers do (or will) accept both formats, so as long as the media type is known it'll work fine for them. But what about every other piece of software in the middle that does not talk
Re: [whatwg] several messages about XML syntax and HTML5
Le 4 déc. 2006 à 11:14, Anne van Kesteren a écrit : For the record. There's no such thing as a lang attribute in the HTML namespace. Except perhaps in some schema's the HTML WG at the W3C is producing but those can safely be ignored. Indeed, it's the lang attribute with no namespace I meant... I made the error of propagating the element's namespace to attributes. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] several messages about XML syntax and HTML5
Le 4 déc. 2006 à 12:30, Mihai Sucan a écrit : html lang=fr xmlns=http://www.w3.org/1999/xhtml; head titleSans titre/title /head body pBonjour à tous!/p p lang=roBună ziua tuturor!/p pimg src=merci.png alt=Merci! id=mon-image //p /body /html Nice example Mihai. To reformulate my previous suggestion more clearly, this example validates for XHTML 1.0 Strict, but it doesn't for XHTML 1.1 with errors on the two lang attributes. (Using W3C's validator.) It happen to be valid HTML5 according to the current spec too (if you add the proper doctype). The question is: should this be valid XHTML5? I think it should. - - - The HTML5 spec currently gives the following authoring requirements regarding lang and xml:lang: The lang attribute only applies to HTML documents. Authors must not use the lang attribute in XML documents. Authors must instead use the xml:lang attribute, defined in XML. [XML] I'd change it for this: Only the lang attribute applies to HTML documents. For XHTML documents, authors should instead use the xml:lang attribute as defined in XML, although the lang attribute is also allowed for backward compatibility reasons. If an element has both the lang and the xml:lang attributes set, both attributes must have the same value. I'm wondering if the two attributes shouldn't be mutually exclusive however, meaning that if one is present, the other must not be. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] several messages about XML syntax and HTML5
Le 4 déc. 2006 à 14:33, Martin Atkins a écrit : Likewise, the content model of the script element is hardcoded into the parser; there's no way to discover it from the syntax alone. (I'll admit that there's no similar construct to the content model of script in XML, however, so this particular difference doesn't pose a problem.) In order to handle custom elements in HTML while still allowing them to appear in the DOM, you'd have to make some rules such as that no void elements are allowed. You'd have to write otherwise- void elements as, say, img/img in order to have them handled correctly by the parser. It's interesting you mention script. If we want some sort of XML data island, we could use something like this: script type=text/xml xml-content/ /script Then, after the content of script has been gathered, the browser could parse it as actual XML, stopping at the first parse error. You could even use JavaScript to gather the text from the DOM, parse the XML and create the DOM tree accordingly since the text content of the script is available in the DOM. The only requirement would be that the XML content does not include any /script itself (See note at the end). I'm not sure if this is a plus or not, but it also seem that this syntax is supported by Internet Explorer's data islands[1], although I assume IE uses its own special parser mode for this. (But I'm just guessing here.) So that's just an idea. I can't say I'm fond of XML data islands myself, nor of the idea of overloading script for this, but I think this method has the merit of being relatively simple to implement. Note: Practically it seems to work with the parser, but it isn't valid since the spec says this about elements such as script: CDATA elements can have text, but the text must not contain the two character sequence /. So for that to be conformant, this paragraph would need to be revised. [1]: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ xmlsdk/html/eb7a2b76-49e9-424c-aa5a-d3cbeeb745e3.asp Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] several messages about XML syntax and HTML5
Le 4 déc. 2006 à 17:19, Lachlan Hunt a écrit : I agree, but how are xml:lang, xml:base and xml:id any more meaningless in HTML than xmlns? In XHTML you can avoid using xml:base (by not specifying a base) and xml:id (by using id). You can't avoid xmlns. That's why I think xmlns comes before these two in order of importance. It is also very difficult to avoid xml:lang which, just like /, can be scattered all over the file. That's why I'm trying to see if there is a possibility of a conformant solution. There's at least a practical solution that will work, which is to use the lang attribute alone, although this isn't conformant with XHTML. The only reason xmlns was allowed was to help ease migration from current XHTML 1.0 to HTML5. Although that logic made sense for '/ ' which you often find scattered throughout many different files, which makes it difficult to update, the xmlns attribute occurs in one place, and that's usually in the same file as the DOCTYPE (in cases where templates are used). Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Provding Better Tools
Le 3 déc. 2006 à 17:04, J. King a écrit : I am. It's not anywhere near finished yet, but the parser so far goes through the whole document and spits out the appropriate tokens; I just haven't done anything with said tokens yet, mainly because I was discouraged by PHP's DOM implementation. My parser is also slow as molasses, unfortunately. My experience optimizing PHP Markdown, and building the custom mixed Markdown/HTML-block pesudo-tokenizer of PHP Markdown Extra, tells me that it'll probably stay very slow as long as the implementation is made of PHP code. Assuming you've implemented the algorithm in the spec as PHP code, you could probably make it faster by using regular expressions in the tokenization steps instead of iterating character by character. For instance, you could implement many of the tokenizer states by matching from the start of a string with a regex. And maybe then it'll also be possible to combine a couple of states within the same regex too. The more we replace PHP code by regular expressions, the faster it'll go, but further we deviate from the processing algorithm described in the spec. I wonder how far we could go while keeping the exact same behaviour. The true good solution would be to have a parser implemented in C and available through every standard installation of PHP. It could be used by other languages too. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
[whatwg] lang vs. xml:lang; id vs. xml:id
The spec tells us: The lang attribute only applies to HTML documents. Authors must not use the lang attribute in XML documents. Authors must instead use the xml:lang attribute, defined in XML. [XML] To determine the language of a node, user agents must look at the nearest ancestor element (including the element itself if the node is an element) that has a lang or xml:lang attribute set. That specifies the language of the node. If both the xml:lang attribute and the lang attribute are set, user agents must use the xml:lang attribute, and the lang attribute must be ignored for the purposes of determining the element's language. While the requirement for authors is pretty clear (HTML: lang; XHTML: xml:lang), it seems to me that the user agent is asked to always favour xml:lang even in an HTML context. Is this really what's intended? I think this ought to be clarified. Also: The id DOM attribute must reflect the id content attribute. Does that mean it should not reflect xml:id even when id is not defined? Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
[whatwg] xml:lang and xmlns in HTML
Le 1 déc. 2006 à 3:47, Henri Sivonen a écrit : On Dec 1, 2006, at 04:15, Michel Fortin wrote: that their valid XHTML1 documents served as text/html, when updated to XHTML5, are now called valid HTML5 documents by the validator. Except: * xmlns is illegal in HTML5. * xml:lang vs. lang. * base vs. xml:base. * meta http-equiv... vs. ?xml version='1.0' encoding=... Ok, fine. The document still has to be non-conformant with one of the two syntaxes, and that's always true since xmlns is required for XHTML but not allowed in HTML. Still, that list of difference is amazingly short. Could it be shorter? Should it be? I wonder if xml:lang and xmlns couldn't be made legal in HTML. xml:lang would simply become conformant in HTML as a synonym for the lang attribute, it's already in the spec that it should get the correct treatment anyway. xmlns would only be allowable on html and only with the HTML namespace as its value. This would make it possible to have documents conformant with both syntaxes at the same time. That's assuming you don't use base or meta http-equiv=; in the cases they're needed they'd have to be changed to xml:base and ?xml ?, but that's a lot simpler to do than to change every instance of lang in a document for xml:lang, and it can be avoided in the vast majority of the cases. This could also help reinforce the idea that it's the media type that differentiate HTML from XHTML. It'd make many valid XHTML1 documents out there conformant with HTML5 with a mere modification to the doctype. Just like for /, xmlns and xml:lang are already pretty common on text/html pages because of XHTML1. I concede however that having the word xml at two places in the HTML language could make things a little more confusing. What do you think? Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] lang vs. xml:lang; id vs. xml:id
Le 1 déc. 2006 à 8:33, Lachlan Hunt a écrit : If both the xml:lang attribute and the lang attribute are set, user agents must use the xml:lang attribute, and the lang attribute must be ignored for the purposes of determining the element's language. While the requirement for authors is pretty clear (HTML: lang; XHTML: xml:lang), it seems to me that the user agent is asked to always favour xml:lang even in an HTML context. Is this really what's intended? I think this ought to be clarified. http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005- April/003652.html Okay, so if I understand well, xml:lang in the spec refers to the lang attribute in the xml namespace, not to the xml:lang attribute in the null namespace that you get with the HTML parser. It makes sense from a DOM perspective, but it's misleading from a markup perspective, so I still think it should be clarified. And although it's less confusing, I think the same should be clarified about xml:id: it's the id attribute in the xml namespace, not the xml:id attribute in the null namespace that you get with the HTML parser. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] lang vs. xml:lang; id vs. xml:id
Le 1 déc. 2006 à 11:44, Ian Hickson a écrit : On Fri, 1 Dec 2006, Michel Fortin wrote: Okay, so if I understand well, xml:lang in the spec refers to the lang attribute in the xml namespace, not to the xml:lang attribute in the null namespace that you get with the HTML parser. It makes sense from a DOM perspective, but it's misleading from a markup perspective, so I still think it should be clarified. Could you propose some text? What about adding at the end of this paragraph: If both the xml:lang attribute and the lang attribute are set, user agents must use the xml:lang attribute, and the lang attribute must be ignored for the purposes of determining the element's language. the following sentence: Note that the xml:lang attribute can only be set via scripting for HTML documents, since the HTML parser does not handle namespaces. I guess that new sentence is totally obvious when you've read the Terminology section, but I still think it's important because xml:lang is used a lot in XHTML1 documents served as text/html, and people will be referring to this part of the spec to know what browsers do about them so it ought to be clear. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] xml:lang and xmlns in HTML
Le 1 déc. 2006 à 11:07, Ian Hickson a écrit : On Fri, 1 Dec 2006, Michel Fortin wrote: I wonder if xml:lang and xmlns couldn't be made legal in HTML. xml:lang would simply become conformant in HTML as a synonym for the lang attribute, it's already in the spec that it should get the correct treatment anyway. Except that wouldn't be backwards compatible since xml:lang= isn't treated as a language attribute in legacy UAs. Yes I see. At the time I thought the spec required xml:lang to work in HTML, because of the way xml:lang is mentioned in the section about the lang attribute. Now I see it's the lang attribute in the xml namespace that would work, not the xml:lang attribute HTML would have. But I think the reverse could work: xml:lang cannot work in HTML, but lang (html:lang) do work in XHTML if I'm not mistaken (although it's non-conforming). This would make it possible to have documents conformant with both syntaxes at the same time. I thought XHTML-sent-as-text/html had explained in painful detail why that's not a desirable end goal. Why would we want this? I don't want to send XHTML as text/html. I want to see if it's possible to have a common subset between HTML and XHTML at the markup level, so that someone can create a document that is conforming both with XHTML to HTML. I'm not sure if this is desirable or not, that's why I was asking for opinions. I see that it may also be completely irrelevant, but I don't really know what to think. This could also help reinforce the idea that it's the media type that differentiate HTML from XHTML. It'd make many valid XHTML1 documents out there conformant with HTML5 with a mere modification to the doctype. Not if they use things like ![CDATA[...]] or the empty element syntax on non-void elements, or any number of other XMLisms. Well, by out there I meant all the XHTML1 documents that are built for text/html, that validates and which don't use any feature that both parser can handle. This certainly does not include ![CDATA[...]]. Sorry if I wasn't clear; out there was certainly misnomer. What do you think? I don't think it's a goal for the two serialisations to have a common subset. That's fine with me. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Allow trailing slash in always-empty HTML5 elements?
Le 30 nov. 2006 à 10:16, Henri Sivonen a écrit : Without labels, I do think that regardless of how the HTML5 spec turns out, WordPress has an architectural flaw in its methodology of producing markup. Since the flaw is in the architecture, I am not optimistic of it getting fixed in WordPress because it would require a rewrite. I'm hoping that at some point, a better system enters the market. Meanwhile, asking the WP developers to rewrite theirs seems unproductive. I concur with that. While it may be true that WordPress often gives valid XHTML1 markup, it can't be denied that the internal processing manipulates pseudo-HTML tag soup at almost every levels, that's not a good architecture if you ask me. Integrating Markdown correctly into the text system of WordPress is a big hack because of that; filters have to be inserted all around the place as workarounds for various issues. I've written on the subject if someone wants to dig deeper: http://www.michelf.com/weblog/2005/wordpress-text-flow-vs-markdown/ The best way someone could fix the resulting tag soup would probably be to pass the result through HTML Tidy. And it should be pretty straightforward since the tidy library has been part of PHP since version 5. - - - For me, accepting / in HTML could be an acceptable solution. It sure is a departure from what was accepted as HTML previously, but I see no point in trying to convince everyone to change (again) their markup for cosmetic reasons. What is really important is that authors understand better that HTML must be served as text/html and that XHTML must be served with an xml media type. If the validator enforce that, then I think it'll be sufficient. What really confused people with XHTML1 is that the validator accepts XHTML1 as text/html without complaining, without even checking that the document will do fine when parsed as HTML. If the validator tells someone that his div/ is perfectly valid for XHTML1 as text/html, it's normal for that person to wonder why it doesn't work in the browser. That's confusing for authors, and that's exactly what we should avoid. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Allow trailing slash in always-empty HTML5 elements?
Le 30 nov. 2006 à 16:46, Sam Ruby a écrit : On 11/30/06, Michel Fortin [EMAIL PROTECTED] wrote: We can't really have a document that is both HTML5 and XHTML5 at the same time if we keep the !DOCTYPE HTML declaration however. Why not? It seems I was mistaken about that. I was pretty sure that it'd be a parse error in XML, but I now look at the [DTD construct in the XML spec][1] and I cannot see why. Apparently this is a valid DTD for an XML document where the root element is html: !DOCTYPE html These wouldn't since XML is case-sensitive: !DOCTYPE HTML !doctype html [1]: http://www.w3.org/TR/REC-xml/#dtd So it appears after all that if HTML allows /, it would be possible and practical to have a single document which is valid for both HTML and XHTML at the same time. That doesn't mean the document will behave in the same way in the two cases however. I wonder if allowing / in HTML couldn't, on the opposite of some other arguments, help authors and developers to grasp the real difference between the two markups. Currently, / is the signature of XHTML; people have learned that you add / to HTML documents to make them XHTML. If HTML embrace the / syntax, then that misleading hint no longer holds and people will have to learn to differentiate HTML from XHTML using other means (hint: media type!). They wouldn't really need to relearn anything if they don't want to, they'll just take note that / doesn't necessarily mean XHTML anymore and that their valid XHTML1 documents served as text/html, when updated to XHTML5, are now called valid HTML5 documents by the validator. Does this scenario makes any sense? Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Subject: Re: many messages regarding image captions
Le 28 nov. 2006 à 9:34, David Walbert a écrit : In principle, I see your point, but I don't see that such broadly defined figures would have widespread practical value. A figure in print publishing traditionally referred to anything that couldn't be normally typeset, but in practice that usually referred to images, charts/graphs ( which in HTML would be inserted as images also), and tables (which in HTML have their own structure and markup). A figure in HTML seems to me to serve the same purpose: to denote and describe illustrative content that cannot itself be marked up with HTML. Then we conceive things differently. A figure in my mind is not something that can't be expressed in HTML. To embed non-HTML content, embed, img, object, and other inline XML languages are used; no need for a figure for that. A figure to me is something that provides support or illustration to the surrounding text. The example from mozilla.org doesn't require any special container element, because it needs no caption. The set-aside text is an example of what's being discussed in the surrounding text, and the heading example serves perfectly well to explain that. But remove the stylesheet and you can see the CSS-generated Example heading disappear. Now, how do you distinguish what is the main text and what is not? I believe that figure class=example would be a better choice than div class=example as it show that the content of the example is not to be taken as part of the main text, but serves as an illustration of what the main text is talking about. Maybe a new example element would be better suited for this, but it seems to me that example and figure often overlap in meaning. Once we say that plain text can be a figure, I'm not sure what meaning figure really has any longer; it could be almost anything. And if it could be almost any piece of text that the author feels is an aside, it will have no semantic consistency, and will then be functionally no different from div. figure illustrative or supporting content for the main content. aside tangential content which can be considered separate from the main content. I think the difference is pretty clear. - - - There is something interesting in the current proposal: it already allows arbitrary content inside it: fallback content. Someone could write: figure legendA nutritional information label on a box of cereal/ legend object data=nutritional-info.jpg table captionstrongNutrition Facts/strong - Per 1/2 cup (125 ml)/caption theadtrthAmmount/thth% Daily Value/th/tr/ thead tbody... replication of the table shown in the picture .../tbody /table /object /figure This would show a picture of the nutritional information label on visual browsers; text readers and text-only browsers would still be able to give an adequate representation of the figure as a table captioned Nutrition Facts - Per 1/2 cup (125 ml). For visual browsers with images disabled, it would be interesting if the fallback table could be styled such as that it resemble the picture. For instance, there is a standard way to lay out nutritional information tables in Canada; I could add a couple of style rules here and there on the fallback content to place borders and margins to match the standard layout. And here lays the irony: if the idea was to display a sample nutritional information table with no other context element, the fallback content may give a better visual representation than the actual picture. Unless the image is vector-based or the table has needs really fancy styling, the styled table will certainly be of better quality than the image. Here is a page which could benefit from such an approach: http://www.hc-sc.gc.ca/fn-an/label-etiquet/nutrition/interactive/ inl_main_e.html If you look closely at the bottom of that same page, you'll see this markup: pstrongBran Cereal/strong/p hr pstrongIngredients:/strong Whole wheat, wheat bran, sugar/glucose-fructose, salt, malt (corn flour, malted barley), vitamins (thiamine hydrochloride, pyridoxine hydrochloride, folic acid, d-calcium pantothenate), minerals (iron, zinc oxide). /p hr which is an illustration of a list of ingredients; completely done in HTML with some text inside a paragraph. A perfect use case for a paragraph as a figure: figure legendBrand Cereal/legend pstrongIngredients:/strong Whole wheat, wheat bran, sugar/glucose-fructose, salt, malt (corn flour, malted barley), vitamins (thiamine hydrochloride, pyridoxine hydrochloride, folic acid, d-calcium pantothenate), minerals (iron, zinc oxide). /p /figure Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Subject: Re: many messages regarding image captions
Le 28 nov. 2006 à 11:09, James Graham a écrit : Broad semantics mean that UAs can do fewer useful things with the information. That dilutes the value of having any semantics at all. Paragraphs are used for so many thing they can hardly be used to extract any information at all, yet they're useful because they're a natural part of every document and they help humans who navigates through the text, either visually or with a text reader. The same can be said for figure: a figure may have a meaning a little more precise than a paragraph, the meaning is still very broad. If you narrow the meaning, you have to change the word, otherwise it'll be confusing. Quoted from Wikipedia: A figure in writing and publishing is any graphic, text, table or other representation that is unaligned from the main flow of text. Figures are commonly found in scientific and non-scientific articles, but also in books. Some books will have a table of figures--in addition to the table of contents--that lists centrally all the figures appearing in the work. http://en.wikipedia.org/wiki/Figure_%28publishing%29 Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] many messages regarding image captions
Le 27 nov. 2006 à 20:49, Ian Hickson a écrit : On Wed, 1 Nov 2006, Michel Fortin wrote: I see no reason to be restrictive on the kind of content that can be captioned. Well, we want the semantics to be well-defined. It's not clear to me what the semantics will be in all cases if we allow anything to be captioned. To me, a figure contains illustrative content attached to a document. It may be an image, a code sample, or a snippet of another document used as an example. I think it's important we do not try to narrow too much what can and what cannot be contained in a figure; that's the job of the author do decide. For instance, lets say an author wants to put a paragraph in a figure. It could be to show how the font is rendered, in which case he may prefer to use a pixel or vector image because what is important is the shape of the characters; it may be to show a particular writing style, in which case it's much better to provide the paragraph as text directly as the text itself is the illustration. In any case, the author knows what he wants to illustrate, and we should allow him to use the best medium for that task. Moreover, I don't think the caption should be mandatory. I know that the primary reason for including a figure element is to have a way to put captions on things, but figure as a simple container for illustrative content has value too. For instance, I would gladly use figure to denote HTML snippets in the following document of my own website: http://www.michelf.com/projects/php-markdown/concepts/ Would this be a valid usage? (Of course, according to the current spec: no. But should it be?) This one in particular: http://politics.guardian.co.uk/homeaffairs/story/0,,1806799,00.html ...suggests we may want to have multiple legend elements per figure, to allow for a caption and photo credit to be given. What do people think? Would some other way of inline giving photo credit metadata be better? I think that could be useful. But my opinion is that it'd probably be better to find a way to do this in the same manner for table captions too. (A table caption citing the source for its data is quite common.) I think it'd be wiser to do this using inline elements inside legend or caption. Why not just embedded elements? Do you really want to disallow inline SVG or MathML as figures? Block-level element, and structured inline-level element. I couldn't really work out why it should be inline. It seems equivalent to a p. I'm not sure about this either; I think it should be like table, and table is declared as such. That's all. Le 27 nov. 2006 à 20:49, Ian Hickson a écrit : I suggest that this element behave in the opposite way from alt=: whereas alt= should be presented only if the image itself is *not* presented, the caption element should be presented only if the image itself *is* presented. Otherwise there would be the same problem with non-sequiturs in non-visual media as there is with descriptive alt=. Agreed; spec now requires this. Not sure how to make this jive with the idea of allowing pre/ol/etc, though; see above. Why would you need a substitue for alt in these cases? I see not need for alternative content when the content is already in text format, or am I missing something? Le 27 nov. 2006 à 20:49, Ian Hickson a écrit : So I propose a new fcaption elements -- for figure caption -- in replacement for the caption element in my previous figure construct: figure fcaptionCaption Text/fcaption img src=... /figure I really want to avoid introducing new elements for concepts we already have... We already have four or so ways of doing caption-like things: caption, legend, label, and title=, not to mention the hx elements, th, and title, which are similar enough that people on this thread have sometimes mentioned them. The more we introduce the more confusing the language becomes. Ok, that's fine. Goodbye fcaption. On Wed, 22 Nov 2006, James Graham wrote: Another issue to consider is the possibility of multiple images with a single caption (this is very common in scientific papers, print magazines, etc.). A construct like figure img img img imgcaption /figure might be enough to support this (the details are, I think, non- trivial); something that requires the caption to point to exactly one image cannot. Hm. This is currently not possible either. I didn't see many (any?) examples of this in the list of sample pages that Michel provided, though, so I'm not sure we need to address this in the first version. What do people think? There isn't many, but there are some. I'll just point out that if you were using the content model I suggested there would be no problem incorporating multiple images in a figure. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] The IMG element, proposing a CAPTION attribute
Le 23 nov. 2006 à 3:32, Alexey Feldgendler a écrit : Anyway, caption is presentational. Oh, please. If caption is presentational, then paragraph and table are as much, if not more. According to my dictionary: paragraph a distinct section of a piece of writing, usually dealing with a single theme and indicated by a new line, indentation, or numbering. table a set of facts or figures systematically displayed, esp. in columns. caption a title or brief explanation appended to an article, illustration, cartoon, or poster. If there is a definition in this list which doesn't suggest some kind of visual presentation, it's the caption. Surely you have a different definition than me. The semantic relation between a caption and its image, or figure, should be exactly what is defined above: a title or a brief explanation. (Definitions from the New Oxford American Dictionary, 2nd edition) Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] The IMG element, proposing a CAPTION attribute
Le 22 nov. 2006 à 5:56, Alexey Feldgendler a écrit : Let's not think of label with type attribute or any other element which is introduced instead as of a visually element. It should be just a way of expressing the value of title, alt etc with rich markup inside. There is already a way to express tooltips in HTML. Yeah, it's rather limited. I'm not against new CSS properties to display things as tooltips, but I'd rather see that confined to custom stylesheets. And reusing label, or even introducing a new element, to override attributes (especially arbitrary attributes) seems cumbersome to me... how do you represent that in the DOM? It is also my opinion that the title attribute, whether it allows rich markup or not, is not the right place for a caption. I'm certainly not going to use it if browsers hide captions in tooltips in their default stylesheets. The default stylesheet needs to be a reasonable fallback, and an image caption must be visible while glancing at the page. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] The IMG element, proposing a CAPTION attribute
Le 22 nov. 2006 à 9:53, Alexey Feldgendler a écrit :
On Wed, 22 Nov 2006 20:42:11 +0600, Michel Fortin
[EMAIL PROTECTED] wrote:
So I propose a new fcaption elements -- for figure caption -- in
replacement for the caption element in my previous figure
construct:
figure
fcaptionCaption Text/fcaption
img src=...
/figure
And if I were to propose a default styling for this, it'd be this
one:
figure { display: table; }
fcaption { display: table-caption; }
figure cannot be used like this:
[...]
Indeed, figure markup cannot express a full table -- but it doesn't
need to. Following CSS 2.1 [1], anonymous boxes are created for rows
and cells wherever appropriate. In the previous example, an anonymous
row and an anonymous cell are created to hold the content of the
figure. The figure effectively behave visually as a one-cell table
with a caption.
[1]: http://www.w3.org/TR/CSS21/tables.html#anonymous-boxes
It works pretty well in browsers that implement `display: table`. And
a not-so-bad fallback for browsers that do not implement the CSS
table display model (IE) is to display both figure and fcaption
as blocks, setting the width explicitly for floated figures (so that
the caption does not extend the box horizontally).
Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/
Re: [whatwg] The IMG element, proposing a CAPTION attribute
Le 22 nov. 2006 à 9:53, Alexey Feldgendler a écrit : figure cannot be used like this: table thead tr thPainting/th thTitle/th thAuthor/th /tr /thead tbody tr tdimg id=img1 src=.../td tdlabel for=img1 type=titleMona Lisa/label/td tdLeonardo da Vinci/td /tr ... /tbody /table Hum, now that I see your example again, I understand that I haven't adressed at all what you meant. Well, indeed that's a limitation of figure: it can't span across different table cells. But on the other side, I don't think I'd call Mona Lisa a caption in your example. It's certainly a title however, and I think the table makes the association pretty clear by itself. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] hash Attribute
Le 13 nov. 2006 à 1:39, ryan king a écrit : On Nov 8, 2006, at 8:28 AM, Ian Hickson wrote: Given the various mechanisms that already exist to do this, it seems like adding yet another one would be a bad idea. I concur. If people are already using these technologies, we could learn from their usage and find ways to improve the technology. If they aren't being used widely, it would be wise to question whether there is demand for this functionality. I'm sure there is demand. A lot of software download pages already give you MD5 or SHA-1 digests values to check the validity of the downloaded file, but it's trouble to check them manually and people rarely do so. I see only two mechanisms that do what the hash attribute would do: it's the hash microformat[1] and link fingerprints[2]. All others require either special URIs schemes[2] which won't work in today's browsers, or are attached directly to the file, like the md5-digest HTTP header, which means that a tampered file is very likely to get its digest updated accordingly. [1]: http://microformats.org/wiki/hash-examples [2]: http://mdhashtool.mozdev.org/lfinfo.html [3]: http://magnet-uri.sourceforge.net/ I'm beginning to think that the link fingerprint method is best solution because the hash is more portable as part of the URL. I could for instance copy a fingerprinted URL right into this email: http://example.com/file#!md5!b3187253c1667fac7d20bb762ad53967 and a knowledgeable browser receiving this URL would know how to check the validity of the received document. The two concerns I have with it is that it somewhat distorts the concept of a fragment identifier, and it's generally going to be lost if there is any redirection (although a browser that knows about fingerprints could keep them across redirections). Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] The IMG element, proposing a CAPTION attribute
Le 10 nov. 2006 à 14:19, Alexey Feldgendler a écrit :
On Fri, 10 Nov 2006 23:47:05 +0600, Steve Runyon
[EMAIL PROTECTED] wrote:
Couldn't we extend the label element to work for images as well
as form
elements? The for attribute would provide the explicit link to
the image
that would take the label's contents out-of-stream for screen
readers, and would likewise (with some CSS changes, I suppose)
allow the caption to be
positioned correctly relative to the image for visual browsers.
Today's browsers seem to have problems about label outside of
form.
And today's browsers also have problems with caption outside a
table, which implies that my previously proposed markup for this:
figure
captioncaption text/caption
... figure content here ...
/figure
would not work correctly in today's browsers. But if you look at
things in another way, today's Firefox can't handle section,
aside, header, and footer correctly either (stopping the
section at the first block-level element!). So it seems that Web
Applications 1.0 already requires browser vendors to do some minor
changes to the DOM unknown markup created previously; maybe
supporting caption or label could be part of these changes.
Also, the last versions of Safari and Opera work fine with section,
but that's relatively new because not so long ago they couldn't.
Should we take this as a sign that browser vendors are willing to do
the necessary changes to work with the new elements? Could such
changes be extended to caption or legend?
What I like about the figure markup above is that it can be styled in
the same way as a table:
figure { display: table; }
caption { display: table-caption; }
which makes figure behave as a one-cell table, and caption behave
as the caption for that table (and you can play with `caption-side:
bottom` too). The only problem is that it doesn't work presently
because caption is completely ignored when outside a table.
Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/
Re: [whatwg] The IMG element, proposing a CAPTION attribute
Le 10 nov. 2006 à 19:16, Ian Hickson a écrit : The difference is that caption will never work, because of things like this: table caption figure img ... caption ...A... /caption /figure /caption ... /table ...which, for legacy compatibility reasons, must result in a DOM where the text with A ends up in a second caption element that is a child of the table element. I don't get it. Are you saying that caption cannot work outside table because it has to work a certain way when inside a table element? Or are you simply saying that figure cannot work because it cannot work inside a table caption? If supporting figure inside a caption is so important, browsers could treat figure in the same way they treat table when inside a caption. This works fine in current browsers: table caption table caption ...A... /caption ... /table /caption ... /table Now, I can't be sure how hard it'd be to make figure behave like table in this specific case, but as I already said. But any of these two samples seems completely ridiculous and confusing to me. Personally, I don't think any of the above cases should be allowed (caption has inline-level content in HTML4 by the way), and I it'd also be fine if browsers continue to do whatever they do when inside a caption element. And I don't see how any of this could prevent caption from creating a caption element in the DOM when *outside* a table. The idea of having markup of this form: -container- -embedded-content-/ -caption- ... /-caption- /-container- ...is a fine idea, however, which has been proposed multiple times, and I'm sure we'll use some variant on that. We just can't use caption. Or label, because that's for form controls. I certainly agree that label is a poor choice, because even if it's not necessarily a bad word for the concept, it's already used to mean something else which has little to do with image captions. I imagine we'll use legend. Parsers are a bit erratic with it right now, but we're requiring them to shape up for the parser part of the spec already, and the details element uses it already. I'm not sure I like legend as a word for captions. A legend -- in the context of a graph, a map, or a schema -- is a list of symbols or colors followed by some definition of what they represents on the figure. It's far different from a caption or the title of a figure. But legend, as an element, is worse: image captions and table captions are much more similar in concept and in default presentation than fieldset legends, which are some kind of title for a thematic group of form controls. By the way, I think legend for details is a perfect choice, because like fieldset, details is a functional regroupment, so legend becomes some sort of title for a group of related user interface elements. That definition works for both fieldset and details. If you add figure into the mix, legend becomes a title for something on the page. I think this would dilute the semantics and make the language less coherent. Even if it's a little more difficult, I think using caption is the right thing to do. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] img element comments
Le 7 nov. 2006 à 14:28, Greg Kilwein a écrit :
Also, if only one of either the width or height attributes is
set, some browsers will scale the other dimension automatically.
Consider this example:
img src=100x50.png width=50
Some browsers will scale height to be 25 in this instance, given an
image with a width of 100 pixels and a height of 50 pixels. This
is quite useful when the height or width of an image needs to be
fixed without distorting the aspect ratio.
You can also do this from a stylehseet in most browsers:
img { width: 50px; height: auto; }
although this works only if the height attribute is not present on
the image. Personally, I often like to use:
img { max-width: 100%; height: auto; }
but again it doesn't work when the height attribute is set, which is
somewhat silly if you see this attribute as metadata about the linked
file while it makes perfect sense if you consider the height
attribute as the desired height of the image on the page.
Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/
Re: [whatwg] hash Attribute
Le 8 nov. 2006 à 0:42, XcomCoolDude a écrit : How about a hash attribute for all elements that link to external files (a, img, etc.)? It would allow you to pass an MD5, SHA-1, SHA-256, or other hash to a user-agent for automatic comparison with the linked file. I'd suggest a format where the hash algorithm is listed, followed by a forward slash and then the hash itself Examples: hash=MD5/9e107d9d372bb6826bd81d3542a419d6 hash=SHA-1/2fd4e1c6 7a2d28fc ed849ee1 bb76e739 1b93eb12 hash=SHA-256/d7a8fbb3 07d78094 69ca9abc b0082e4f 8d5651e4 6d3cdb76 2d02d0bf 37c9e592 I wonder if checksum wouldn't be a better name: it contains the word check which better describe the purpose of the whole thing. But whatever the name, I like the idea of having an automatic mean for the browser to check the validity of downloaded documents. Many download pages already offer such checksums, but I rarely take the time to check manually after the download. Charles Iliya Krempeaux suggested to include the hash as an HTTP header. This would cover the case of an error in the transmission of a document, but it wouldn't in the case a file got maliciously modified on the server. In many cases, the web page for downloading the file is on a different server than the file itself; by providing the hash on the download page and checking it against the actual file you've received you get additional security against malicious file substitutions. This becomes increasingly important when files are mirrored on a couple of servers at different locations. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Footnotes, endnotes, sidenotes
Le 6 nov. 2006 à 12:32, Sander Tekelenburg a écrit : Another thing is that whether the annotation should be considered a footnote, endnote or whateverelsenote seems to me a presentational issue, so I'm not that enthusiastic about calling it a footnote element. Why not simply annotation? You can then allow the author to decide where in the page, or in a group of pages, to place the annotation element, and use CSS for the presentational aspects. (You could allow the same with foonote, but that name suggest it must only be used for footnotes.) I agree that it's a problem with the name footnote. On the other side, annotation makes me think of something the user added in the margin, while footnote better evoke the complementary relation a footnote has with the text. While I prefer footnote, I think both can do fine. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] [HTML5] 3.10.9. The |abbr| element
Le 1 nov. 2006 à 21:44, Jonathan Worent a écrit : I disagree. There is never a guarantee that people will know what an abbreviation stands for, I know what AIDS is but not what it stands for. Also accessing the title information is optional. If the user knows what the abbreviation stands for they won't need to access the title information. There are plenty of better reasons to omit title. I can think of three right know: What if the author doesn't know what an abbreviation stands for? It could be a fictional abbreviation, or it could be an author asking his readers for the meaning of this particular abbreviation. What if the author does not want to disclose the meaning of the abbreviation? The meaning could be a question in a quiz. And what if the abbreviation has two meanings at the same time? For instance, how would you markup the first CSS acronym of the second paragraph here: http://people.opera.com/howcome/2002/dvd/index.html There are legitimate reasons to not fill up the title attribute of abbr. Or should abbr be disallowed in these situations? Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] caption (was: How not to fix HTML)
Le 1 nov. 2006 à 22:01, Jonathan Worent a écrit : I think this is a good idea. Caption could be used with just about any embedded content. Taking cues form the label element for forms you could either make the association explicit by wrapping the caption around the element its captioning caption embed ... A funny video of a man being hit in the groin by a football /caption or make the association implicit by using the for attribute embed id=funnyVid ... caption for=funnyVidA funny video of a man being hit in the groin by a football/caption I think what would work best for this is the figure element I've proposed back in june: figure captionSome caption here/caption ... /figure where ... could be an image, flash or video content, inline or external SVG or MathML or anything else. It could be made of block- level HTML elements too: code could be used for captioned code snippets, paragraphs and headers could be used when you need a sample document, etc. I see no reason to be restrictive on the kind of content that can be captioned. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
[whatwg] Footnotes, endnotes, sidenotes
Le 30 oct. 2006 à 15:33, Ian Hickson a écrit : * note and reference for footnotes, endnotes, and sidenotes (not aside in “HTML5”) Yes, this is an area where document and converter authors currently need to come up with their own class-based hacks. Ideally a continuous media user agent could show footnotes in context so that they don't become de facto endnotes. If anyone has any ideas on this, please post them to the list. (The CSS group is also looking at footnotes closely.) 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. Would the title attribute be suffisent? I don't think so. The main problem being that an attribute cannot contain any markup (links, emphasis, paragraphs?). I'm all for a syntax for footnotes (and sidenotes, and endnotes). The question is what do we want a footnote markup to accomplish? Minimally, it should associate a note with its context so that you know there is a note and that you can refer to it if you want. This definition encompass a couple of methods to do such notes that are in use currently, in HTML and elsewhere. 1. One of them, mostly used with sidenotes, is to have the note directly in the text: pSome text span class=sidenotethis is a sidenote to put in the margin/span and some other text./p With pretty trivial CSS, you can then put all the sidenotes in the margin. With some javascript[1], you can also create a list of footnotes at the bottom of the page. This method is also consistent with how word processors treat footnotes: as distinct pieces of text inserted punctually at some place in the main text but which are rendered elsewhere. [1]: http://www.brandspankingnew.net/specials/footnote.html 2. Some syntaxes meant to be written directly by humans, like Latex, also allow you to defer the note content until a later time to make things more readable. In these cases, you put a marker in the text, then associate the marker with the note content which can be placed elsewhere in the document. This make the text more readable. My own text-to-HTML tool (PHP Markdown Extra, semi-private beta version 1.1) use such a syntax: Paragraph linked to a footnote[^1]. [^1]: This is the footnote content. Some other paragraph. I'm not aware of anyone doing this for footnotes or sidenotes in HTML; it doesn't seem very practical to style either. 3. The last method of expressing footnotes in HTML is to create markers in the text and put the footnotes in an ordered list at the bottom of the page. For instance, my text-to-HTML tool generates this markup from the above example: pParagraph linked to a footnote supa id=fnref:1 href=#fn:1 rel=footnote1/a/sup. /p pSome other paragraph/p div class=footnotes hr / ol li id=fn:1 pThis is the footnote content. a href=#fnref:1 rev=footnote↩/a /p /li /ol /div This provides a trivial way to style footnotes as footnote, it'll even looks good unstyled and is completely backward compatible. - - - Before defining a markup for footnotes or sidenotes, I think it'd be a good idea to see what goals the syntax should fulfill. Is backward compatibility one of them, or should we always rely on the browser capabilities to relocate footnotes where they should be, or should we allow both? Some other things to take into consideration: * Footnotes should probably not be allowed to escape their enclosing article element. For instance, if you have a couple of weblog articles on your main page, each article having some footnotes, it'd probably not be a good idea to have footnotes from all articles mixed together in the same list. * Although not necessarily very common, some people like to put multiple paragraphs, lists, and some other block-level elements in footnotes and sidenotes (more often seen in sidenotes in books). I think it'd be a good idea to allow that in the markup. * Sidenotes may not be achievable in the browsers's default stylesheet without adding a side margin. They could always be displayed as float, but it seems to me that footnotes would be the best fallback mechanism. Sidenotes are also impractical on small screens too. That's why I believe that, ideally, footnotes and sidenotes should share the same markup, styling is what should make the difference. I'm not yet proposing any markup, I want to start the discussion on what it should accomplish, and what is realistic. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
[whatwg] Dialogue and inline quotations
I think if HTML5 deprecate the use of dl for dialog, that it ought to provide a an alternative syntax for them. I know it has already been discussed, but I'd suggest this: dialog pciteMe:/cite qCan I say something?/q pciteHim:/cite qNo!/q /dialog In this design, dialog is optional, only needed when the dialog needs to be separated from the main text, q is optional when inside dialog, and cite can be omitted if the interlocutor name is not specified. This leaves much flexibility when writing dialogs, and thus allows the markup to be used for dialogs at places dl could not. For instance, this is a dialog, but since its mixed with the main text you can't surround it by dialog. Also, using cite in here isn't very practical, as the text refers to the speakers as he or she most of the time. pHe was downstair when he heard a strange noise from outside. When he went to see, he saw Julietta in the park screaming at him: qWhere were you?/q/p pqI was busy fixing the pipes. What happened here?/q he asked./p pqThere was a cat on the tree/q, she said. qIt jumped and landed in here./q She was pointing at a crate full of pieces of metal. qI jumped!/q/p It's interesting to note however that the same text could be surrounded by dialog tags when formatting the same dialog in French. In the following example, q must be styled with no marks and add em dashes must be added at the start of each paragraph in the dialog (this could be done by CSS, although here I've done it in the source for clarity): pIl était au sous-sol quand il entendit un bruit étrange venant de dehors. Quand il est alla voir ce qui se passait, il vit Julietta dans le park qui lui cria:/p dialog p— qOù étais-tu ?/q/p p— qJ'était occupé à réparer les tuyaux. Qu'est-ce qui c'est passé ici ?/q a-t-il demandé./p p— qIl y avait un chat dans l'arbre/q, dit-elle. qIl a sauté pour atterrir juste là./q /dialog pElle pointant une caisse pleine de morceaux de métal./p dialog p— qEt j'ai fait le saut !/q/p /dialog Note that without q in the previous example, there is no easy way to distinguish inserted text like dit-elle (she said), these are typically disambiguated from context in French. But I'd consider the q element optional anyway, even if omitting it leaves this ambiguity. The reason being that there is no way to disambiguate inserted text inside inline quotations either. What I did in the previous dialog requires the removal of the quote characters in the styling of q, but to be consistent you'd need to do that with inline quotations too, which goes against both the recommended usage and the default stylesheet for q: « qPourquoi se déplacer ?/q dit-elle. qOn a pas besoin de vous/q » Personally, I think this is how q should have worked from the start, but it may be too late to change that. Anyway, let's return to the subject of dialogs. The second type of dialog I considered is more like in a theatrical piece, where dialogs are completely free of any other prose. It was previously suggested in HTML4 to use dl for this: pMary and Mark begin walking in the park./p dl dtMary/dt ddSo where do you want to go tomorrow? I can tell you already have something in mind./dd dtMark/dt ddWhat makes you think that?/dd /dl I think it'd be better expressed this way: pMary and Mark begin walking in the park./p dialog pciteMary:/cite So where do you want to go tomorrow? I can tell you already have something in mind./p pciteMark:/cite What makes you think that?/p /dialog Here, q tags would be optional because the dialog element already implies that everything in the paragraphs is part of the dialog. And since q adds quotes, which are not desired in this case, it'd probably be a bad idea to add it anyway. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
[whatwg] Element name expressiveness
That's a personal opinion, but I think it may have some value. I find the proposed x and t elements to lack expressiveness in their names. I understand that making them shorter is desirable, but it also has a drawback: they're harder to understand simply by looking at the source and their meaning can more easily be misunderstood. Not everybody read the spec and those that don't are more prone to use them inappropriately. Personally, I'd favor term and time instead, or anything else that conveys a meaning. That's especially important since these element will have, most of the time, no noticeable effect on the visual representation of the document. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Lists, ins/del, and a
Le 30 août 2006 à 2:49, dolphinling a écrit : What's more, it's not backwards compatible. I would *love* it if it were (especially because then fieldset could also go there, and repetition template attributes wouldn't have to apply to all elements), but current UAs turn ulinslitext/li/ins/ul into ins/insullitext/li/ul. Safari, Mozilla and Opera all seems to build the DOM tree as it should, wherever I try ins, del, or a, or even fieldset. Are you talking solely about Internet Explorer for Windows (which I haven't tested) ? While it works fine with ul I note that it doesn't within table, showing the same behaviour as in your ul example above. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Lists, ins/del, and a
Le 29 août 2006 à 23:00, Lachlan Hunt a écrit :
Michel Fortin wrote:
How can we markup removed or inserted list items? Here's a general
idea:
ul
insliSome list item/li/ins
delliAnother list item/li/del
/ul
This can be solved by putting the ins and del elements as the only
child nodes of the li elements instead.
ul
liinsSome list item/ins/li
lidelAnother list item/del/li
/ul
The meaning of your markup is that you inserted and deleted some text
within each list item, not that you added or deleted a list item like
in mine. Semantically there is a difference, subtle maybe but still
there.
Also, while your markup gives the same visual rendering while using
the default browser stylesheet (which underlines ins and
overstrikes del), the result will be completely different if you
want to hide the inserted or deleted parts. Using this CSS rule:
del { display: none }
you'll see a one-item list for my markup, while for your markup
you'll see a second, empty list item.
Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/
Re: [whatwg] About adopting quirks mode parsing
Le 18 juil. 2006 à 21:43, Ian Hickson a écrit : It might be desirable also that a valid HTML4 document gets a conforming HTML4 DOM. If it is, then ps shouldn't contain table. I agree. Is this goal compatible with blockquote, pre, ol, ul, and dl being structured inline-level elements? Let's take this valid snippet of HTML 4: pSome text ulliList item/li/ul According to HTML 4 parsers, I believe the DOM will be: P #text: Some text UL LI #text: List item But in HTML 5, where the list can be part of a paragraph, shouldn't the list be put inside the paragraph? Giving this DOM: P #text: Some text UL LI #text: List item Or should the list be put inside the paragraph only when you have an explicit closing p tag following the list (so that it becomes invalid HTML 4): pSome text ulliList item/li/ul/p ? Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] image captions
Le 28 juin 2006 à 21:17, Lachlan Hunt a écrit : Michel Fortin wrote: figure captionFigure 1: Some image/caption img src=... /figure [...] The only problem is that it isn't very backwards compatible. Firefox doesn't include caption in the DOM outside of a table. Moving the caption after the image in the source and setting display: block; on the image gives reasonable results in Firefox and Opera because the img is a child of figure, but not in IE because figure and img are treated as siblings. I have exposed this problem previously (look back at this thread in April). In fact, my first thought was that this was a show-stopper for that particular syntax and that a substitue ought to be found. Then I realised that, contrary to my first belief, others elements in the current draft -- namely section, nav, header, footer, aside, and maybe others -- aren't backward compatible either because they can't contain even a paragraph, at least in Safari and Firefox. Will this prevent section and others from being adopted? I doubt it. Should this prevent a figure element from being adopted? I don't think so. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] image captions
Le 28 juin 2006 à 16:01, Ben Meadowcroft a écrit : Perhaps a better method would be using the longdesc attribute to associate a caption with an image. Specifically we could point the image to fragment within the current page and give an explicit association in this manner. img src=man.gif alt=A Man longdesc=#manCaption / p id=manCaptionA more full description of the image/p Does anyone know how screenreaders and other assistive technologies handle longdesc URIs pointing to fragments within the same page? Interesting idea, but longdesc cannot be used with object, embed or embedded XML (SVG for instance). Moreover, a caption isn't always a description. Also, if the caption isn't identified as a caption by some mean (say with a caption class), styling is not easy and the caption paragraph can be confounded with another paragraph else. The common practice of having the illustration and its caption together, either floating on the side, indented, or spaning into the margin cannot be easily realised without additional, non-standard markup. People would then come again with different markups to solve the same problem of displaying a captioned image on screen, and we wouldn't have achieved much. The idea I proposed earlier (May 3): figure captionFigure 1: Some image/caption img src=... /figure makes it easy to style figures correctly, it can markup an image as a being a figure without the need of having a caption, and can accept anything as an illustration (img, object, SVG, MathML), even HTML (for sample code[1], tables used as figures, ordered and unordered lists of images, or text samples). figure has the semantics of being an illustration of what is expressed in the surrounding prose, as opposed to img alone which can be seen as an image replacement for the content of its alt attribute at the place it is inserted. The figure caption is coherent with the way captions are inserted inside table. It also makes impossible to detach the caption in the markup by placing it at the other end of the document, something you could do with an idref and which may be a good or bad thing depending what we want to achieve. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Spellchecking proposal #2
Le 22 juin 2006 à 12:04, Ian Hickson a écrit : UAs should use the language of the element to determine what spelling and grammar rules to use. (Language information can come from the lang and xml:lang attributes, Content-Language HTTP headers, or other sources. q.v.) Maybe having the possibility to set the lang attribute to a value meaning not a language would be enough to disable spellchecking when the content isn't a human language. And if you want to explicitly tell a field to use spellcheck you'd use any valid language code, or the empty string which currently mean unknown language. Would this make sense? Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Mathematics in HTML5
Le 22 juin 2006 à 3:52, White Lynx a écrit : Adding CSS extensions makes sense, but I fear it could take infinite time, therefore it is better to keep markup within XML/CSS2.1 framework so we could start using it today and then gradually improve situations on CSS side. It will surely take some time. But we also have two open-source and widely-used html/xml/css rendering libraries, so, if there is enough interest, and if the changes are easy to implement, someone could add the CSS extensions to the libraries and the browsers that use them. I took a look at the WebKit source for the first time this morning and I think I found exactly how I could implement the CSS features I've talked about. Maybe I should give it a try. What I fear is that if HTML standardize an inelegant syntax based on presentation it may come bite us later on if/when CSS has improved. Beside, stretchy parenthesis/braces/chevrons/roots don't seem to be in the reach of CSS 2.1 anyway, you'll still have to wait new styling improvements for these pretty essential parts, it could be long too. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Mathematics in HTML5
Le 21 juin 2006 à 7:16, White Lynx a écrit : 1. formula, dformula, dformgrp - just containers, no problems. 2. sub, sup - already exist nothing to add 3. stack - requires support for inline-blocks. No problems in MSIE, Opera, Prince. Safari and Mozilla will have to fix bug affecting inline-blocks. 4. fraction, num, den - the same as stack. I. Full proposal II. 1,2,3,4,5,6 with restricted content of ubase, 7, 10, 11 (Juan's proposal) III. 1, 2, 4 (Michel's proposal) My proposal was fractions, and *only* fractions. I never included formulas in it. I think that any kind of formula element would be a little silly if we are to only offer fractions to authors. I'm not really opposed to formula per se, I think however that dformula and dformgrp are superflous. So, using your list, my proposal was really 2 and 4, and nothing else. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Mathematics in HTML5
Le 21 juin 2006 à 13:29, Alexey Feldgendler a écrit :
On Wed, 21 Jun 2006 21:48:25 +0700, Michel Fortin
[EMAIL PROTECTED] wrote:
1. Some border-character property, which would work mostly like
CSS 3's border-image, but would put a stretchable character in the
border. The browser would be in charge of stretching. border-
image with SVG could be an adequate substitute for some
characters, but I'm not sure it would be so great with braces or
arrows.
border-character isn't going to work. When scaled non-
proportionally, characters get ugly, with horizontal elements
getting thick. The { and } characters will suffer the most from
this. TeX applies custom logic to stretchy braces, and I think we
shouldn't try to make ANY character stretch automatically.
Well, my idea was that the stretching logic would be character- and
implementation- specific. A nice browser would stretch braces using
its own elegant way, while an ugly browser could use linear
stretching or no stretching at all.
4. In the same reasoning, it would be great if there was a way
adjacent
elements could share the same horizontal space, like sup
and sub
when they are next to each other:
Csup1/supsub2/sub
I'm thinking of something which I would call inline-float (for
the lack of a better name), which would make two or more
elements
with that property collapse into the same horizontal space when
they are following directly each other and are not overlapping
vertically.
1. They would also need to be aligned either to left or right (to
accomodate prefixes to chemical symbols).
The way I was thinking about it, you would have: inline-float:
left, inline-float: right and inline-float: center to align
horizontally the element's box inside the collapsed area.
2. This isn't going to work correctly when the subscripts and
superscripts are complex (e.g. fractions). In your proposal,
they'll fail to stack and will go one after another. What should
happen is that they should still be one above another, just
occupying more vertical space.
You're right, that's a pretty valid criticism that I haven't thought
about. But if I bring back my third point suggesting new values for
vertical-align based on the preceding character's or element's
height, we could arrange the meaning of such values as to make
vertical overlap impossible.
Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/
Re: [whatwg] Mathematics in HTML5
Le 21 juin 2006 à 12:00, White Lynx a écrit : Michel Fortin wrote: 4. In the same reasoning, it would be great if there was a way adjacent elements could share the same horizontal space, like sup and sub when they are next to each other: Csup1/supsub2/sub To avoid changes on CSS side in current proposal this is achived via special HTML parsing rules that treat adjacent indices as stacked. sup1/supsub2/sub = stacksup1/supsub2/sub/stack I know that. But special parsing rules, just as new CSS properties, need changes to happen in the browser. If someone is going to improve the browser, it'd be much better to improve the presentational layer with a few reusable CSS rules than to add a collection of specific- case parser rules changing the DOM for presentational reasons. I'd also add that better support for combining diacritics in Unicode, designed to stack over each other, would be great for maths too. They already are expected to stack over each other. And that's why I was asking for better support, not design, in the sentence above. I mentioned they were meant to stack in case someone missed that from one of the previous 195 messages of that very long thread, but I admit it could have been formulated better. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Mathematics in HTML5
Le 20 juin 2006 à 3:40, White Lynx a écrit : Yes. The same markup is used in ISO 12083, AAP Math DTD and most of other DTDs that I have seen, modulo naming conventions this markup is: fraction numnumerator/num dennumerator/den /fraction That was what I had in mind. I used to prefer frac over fraction, but I'm not sure anymore, both would work with me. I believe fractions can also be somewhat useful outside the realm of mathematical formulas. And a fraction construct would encourage implementors to fix their inline-block and vertical alignment CSS bugs, opening the door to more CSS-based mathematical markup in the future. Very well. So at least add ISO 12083 fractions construction to HTML, it works in MSIE 6, Opera 9, Prince 5 http://www.geocities.com/chavchan/frac/fractions.xml With one small bug fix it will work in Safari and PDFReactor, with more complex but still one bug fix it will work in Mozilla too (Gecko bug is expected to be fixed in near future). Fractions work in XSL FO too, for instance Antenna XSL Formatter 4 can handle them using fo:inline-container. ... and, by using custom stylesheets for these browsers, it can also work reasonably well in current versions of Gecko and Safari, both with unperfect but not-too-bad vertical alignement. The whole fraction would be vertically centered instead of having its bar aligned relative to the text baseline, which would give mostly the same result unless the numerator and the denominator have different heights. The only issue is how to feed them with a separate stylesheet... Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Mathematics in HTML5
Le 17 juin 2006 à 7:01, White Lynx a écrit :
Yes, sup/sub will work like in HTML. This behavior is not perfect
in case
of resizable operators, fences, matrices and vectors however in
this cases operator limits (llim/ulim) and fence markers (marker/
submark) provide necessary functionality.
That's what I thought. I'm not sure I like the idea of expressing
exponents using either sup or ulim depending on what's preceding
it. So I thought I could suggest something else.
The goal of fence is to have resizable fence delimiters around an
expression. What makes fence so difficult to implement (hence the
abstract fenced element) is that it must support any arbitrary
height. But even with the help of fenced a big problem remains:
with current CSS capabilities, it is difficult to display arbitrary
sized parenthesis or braces, or anything requiring more than what can
be implemented using CSS borders.
I think all of this can be solved with one tiny change of paradigm.
Instead of having fence decide itself of its size (which doesn't
work with all kind of delimiters anyway), we could let the author
decide of the delemiter's size around fence. If we had a size
attribute, or something like that, with a list of predefined sizes
for for fence, authors could choose the appropriate size according
to the content. Different CSS rules could decide what to do for each
size:
fence size=medium.../fence
fence[size=medium]::before {
content: url(open-medium-parenthesis.png);
}
fence[size=medium]::after {
content: url(close-medium-parenthesis.png);
}
And, to return to my first point, elements following fence (like
sup) could be aligned according to the fence's size:
fence size=medium.../fencesup2/sup
fence[size=medium] + sup {
vertical-align: 5em;
}
Fence markers could be implemented in a similar way, and then you
would no longer need a fenced element.
All this remains to be tested. I'm not sure it will work that well
with text zoom for instance. But it could simplify the markup as well
as it would solve the resizable delimiters problem. I know it's not
ideal, but it could be a workable solution for current browsers. The
manual sizing restriction could be waived one day if CSS capabilities
improve.
It doesn't solve the thing for matrix though.
Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/
Re: [whatwg] Mathematics in HTML5
Le 16 juin 2006 à 9:27, White Lynx a écrit : Yes, sub/sup will behave like HTML sub/sup with offsets being based on font size like it is currently done in HTML implementations, while llim/ulim and marker/submark will have offsets based on size of their base (operator, fence, matrix etc.) not font size like in case of HTML sub/sup elements. Am I right to say than an exponent made with sup following a fence of a undefined height cannot be aligned correctly vertically? Could the same thing be said when sup is preceded by a matrix? Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] On accessibility
Le 14 juin 2006 à 21:09, Lachlan Hunt a écrit : If implementations can be modified so that accesskeys do not interfere with existing shortcut keys, then that's great. Perhaps they could offer a kind of web-apps mode where all Alt+[key] combinations are safe to be used by the web page, and then another mode where they retain their normal browser functions. But until something like that happens and proves successful, accesskeys should not be retained. I'd like to point out that accesskeys are working very well on the Mac. Application commands are issued using the Command key and most browsers bind accesskeys to the minimally-used Control key. Accesskeys do not conflict with other system and application shortcuts unless the user defines his own conflicting shortcuts in the system preferences. It would be sad to see accesskeys disappear just because they are hard to implement elsewhere. But I acknowledge most other computers don't have a spare key which can be used for that. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
