Re: [whatwg] img element comments
On Tue, 07 Nov 2006 03:49:40 +0100, Matthew Paul Thomas [EMAIL PROTECTED] wrote: In 1998 I used a version of iBrowse for the Amiga that treated img width= and height= in the way Ian proposed -- as preliminary advice on the dimensions of the image, reflowing if the actual dimensions turned out to be different. I thought the proposal was that only that (setting height and width to the intrinsic size of the image) would be conforming, but that rendering would still be the same. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
[whatwg] img element: downloading a resource
The definition of downloading a resource must be clear that even if the resource does not need to be downloaded (because it has been cached or something) the load event still needs to be dispatched (or the error event, in case it contains errors). -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Footnotes, endnotes, sidenotes
Michel Fortin wrote: Le 6 nov. 2006 à 7:04, Matthew Raymond a écrit : Michel Fortin wrote: 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 have a similar view, although I have some refinements: | p annotation=my-footnote | This paragraph has a footnote | a rel=annotation href=#my-footnotesup[1]/sup/a. | /p | [...] | footnote | pReferences:/p | al | ol | li id=my-footnote | pThis footnote can contain block-level elements!/p | /li | /ol | /al | /footnote I think having an annotation attribute in the paragraph is redundant with the a rel=annotation element. What happens if the attribute is there and there is no link? Then there's no fallback for legacy user agents. Is your argument that fallback should be structured in such a way that it must be included? (Not that that isn't a valid argument...) What if the link is there with no annotation attribute? While you could imply that the a rel=annotation element applies to the immediate parent, there is not explicit markup that indicates the scope of the annotation, and readability is negatively impacted because the scope could start well before the a element occurs in the markup. Also, because a dictates the position of the annotation link, you're essentially dictating part of the styling. What if the user wants to move the annotation link to the beginning of the annotated text rather than the end? Or vice versa? While CSS3 may have some solutions, it's not something for beginners. I think the attribute is completely unnecessary. I disagree. Just |rel=annotation| could just be a microformat to anyone reading it, and it doesn't clearly establish the scope of the annotation. Also, you're mixing two different terms (footnote and annotations), I don't think that's a so good idea. I'm not married to the whole footnote idea. That was just there to give a structured higher-level container to the annotation list (al). And you're forcing your annotations to be part of a list, which makes difficult to put them in the middle of the text to style them as sidenotes. We could have annotation elements with optional annotation list parents: | annoAnnotation/anno | | al | annoAnnotation 1/anno | annoAnnotation 2/anno | annoAnnotation 3/anno | al | | annoAnnotation/anno | annoAnnotation/anno Or perhaps just drop the al, but I like the idea of that list type for numbering and reordering purposes. The user agent could reorder the items to the order they're linked to.
Re: [whatwg] img element comments
On Nov 4, 2006, at 08:37, Ian Hickson wrote: I'm thinking of only allowing integer values, and requiring them to be equal to the dimensions of the image, if present (and requiring both to be present if either is present). Would people be ok with that? Suppose there are desktop systems in the near future that double the pixel density of the display compared to what is common today. Considering the handheld displays Nokia ships, I guess it is only a matter of time for similarly small pixels to appear in desktop-sized panels at affordable prices. Apple already seems to be preparing for this. To render legacy pages, browsers will probably have to define 1 CCS px to be equal to two device pixels and render each image pixel of legacy bitmaps as 2 by 2 device pixels. Now if an author wants to deliver more precision to such new systems while being compatible with legacy systems, the reasonable thing to do is leaving the width and height attributes to values that would make sense for legacy systems and to quadruple the number of samples in the bitmap by doubling its pixel height and width. So I think width and height should not have conformance requirements tied to pixel dimensions of the references image file. They are presentational, but they are such a useful presentational optimization that I think it doesn't make sense to try the get rid of that presentationalism just to comply with a principle. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] img element comments
On 11/7/06, Anne van Kesteren [EMAIL PROTECTED] wrote:
I thought the proposal was that only that (setting height and width to the
intrinsic size of the image) would be conforming, but that rendering would
still be the same.
Yeh, in example method, this is the suggestion:
(at least from what I got out of the proposal)
[conforming]
img src=276x110.png alt=fallback text title=description
img src=276x110.png width=276 height=110 alt=fallback text
title=description
[non-conforming]
img src=276x110.png width=400 height=200 alt=fallback text
title=description
img src=276x110.png width=50% height=50% alt=fallback text
title=description
img src=276x110.png width=276 alt=fallback text title=description
Note: For backwards-compatibility, even though these are
non-conforming, the width and or height attribute values are still
applied to the image for rendering (if css doesn't override).
[encouraged if you need to resize the image]
selectorThatMatchesTheImage {
width: 400px;
height: 200px;
}
img src=276x110.png width=276 height=110 alt=fallback text
title=description
[encouraged if you need to resize the image - alt]
img src=276x110.png style=width: 50%; height: 50%; width=276
height=110 alt=fallback text title=description
If that's correct, doing things the proposed, encouraged, conforming
way seems fine as far as UAs that support css are concerned.
--
burnout426
Re: [whatwg] img element: downloading a resource
On Tue, 07 Nov 2006 15:39:56 +0600, Anne van Kesteren [EMAIL PROTECTED] wrote: The definition of downloading a resource must be clear that even if the resource does not need to be downloaded (because it has been cached or something) the load event still needs to be dispatched (or the error event, in case it contains errors). Even for data: URIs? And what about img.src = img.src; ? The image surely needs not be downloaded again, but should the load event fire? -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Object data Attribute
Me: Reason 3: The tcl plugin http://www.tcl.tk/software/plugin/ suports inline scripts via a script param and things like the following need to work with the data attribute. Sorry. Correction. That's WITHOUT the data attribute. -- burnout426
Re: [whatwg] Object data Attribute
On 11/6/06, Lachlan Hunt [EMAIL PROTECTED] wrote: Hi, Should the data attribute be required for object? There is at No. Reason 1: object classid=java:MyJavaClass/object is used for Java. ( Although I'd love to have object type=application/java data=file.class/object work, but ...) Reason 2: You might want to load a plugin like this: object type=application/x-mplayer2/object and later use scripting to tell the plugin to get the resource. If the data attribute is required, you'd be forced to load a resource that you didn't want to. Reason 3: The tcl plugin http://www.tcl.tk/software/plugin/ suports inline scripts via a script param and things like the following need to work with the data attribute. object type=application/x-tcl param name=script value=script content /object -- burnout426
Re: [whatwg] img element comments
On 07.11.2006, at 19:49, Shadow2531 wrote: On 11/7/06, Anne van Kesteren [EMAIL PROTECTED] wrote: I thought the proposal was that only that (setting height and width to the intrinsic size of the image) would be conforming, but that rendering would still be the same. [encouraged if you need to resize the image - alt] img src=276x110.png style=width: 50%; height: 50%; width=276 height=110 alt=fallback text title=description If that's correct, doing things the proposed, encouraged, conforming way seems fine as far as UAs that support css are concerned. Don't forget that percentage values are relative values. And in current browser implementations, setting those values via CSS-rules or using width- and height-attributes are leading to different results! It's due to different parents to calculate actual (pixel) values from! CSS values are relative to the the parent element in HTML tree: div style=width: 100px; height: 100px; img src=276x110.png style=width: 50%; height: 50%; /div = displays image 50x50px. Attributes values are relative to the actual size of the image: img src=276x110.png width=50% height=50% = displays image 138x55px. That may be very useful in many cases, so as a HTML-coder, I don't think anybody should change that behavior without proposing something to replace it. -- Andreyka Lechev [EMAIL PROTECTED]
Re: [whatwg] img element comments
Andreyka Lechev wrote: On 07.11.2006, at 19:49, Shadow2531 wrote: On 11/7/06, Anne van Kesteren [EMAIL PROTECTED] wrote: I thought the proposal was that only that (setting height and width to the intrinsic size of the image) would be conforming, but that rendering would still be the same. [encouraged if you need to resize the image - alt] img src=276x110.png style=width: 50%; height: 50%; width=276 height=110 alt=fallback text title=description If that's correct, doing things the proposed, encouraged, conforming way seems fine as far as UAs that support css are concerned. Don't forget that percentage values are relative values. And in current browser implementations, setting those values via CSS-rules or using width- and height-attributes are leading to different results! It's due to different parents to calculate actual (pixel) values from! 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. -- Greg Kilwein [EMAIL PROTECTED]
Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5
I thought Joe Clark's opinions and criticisms of the WHATWG and HTML5 might be of interest to people here. http://blog.fawny.org/2006/10/28/tbl-html/ I don't agree with everything he said, but he points out a lot of issues and lists several limitations and suggestions. Some of the suggestions are already included or have at least been discussed, but some a new and worth looking into. I would like to put this into discussion: A view into the past: In the beginning HTML's only ability to define presentation was through tags (with predefined visual behaviour/presentation) and it's modification through attributes. This obviously leaded to the invention of tags for presentational purposes. The definition and invention of tags, it's semantic and presentational meaning was (and is) developed by various groups with various interests, browser-developers (who sometimes also re-used HTML for alienous applications), work-groups and companies that really re-(or miss-)used HTML for their proprietary needs. Most of these groups developed/extended HTML under a commercial point of view: 'How can I offer a feature more excessive and faster than the others'. It was rather not developed under the LCD (least-common-denominator) of all participants, long ignored (and still yet) the end-user. With the shift of presentational definition away from tags and inline- attributes to CSS, and shortly after the introduction of free-formable HTML (in the sense of tag-name freedom) by XML the situation has fundamentally changed, is fundamentally different. The situation: From a technical point of view there don't exist a reason of existance for the majority of the tags anymore (in effect most browsers do NOT make any difference between the majority of the tags, with the ONLY exception that they have different CSS-templates, which is a consequence of the transition of the ability of the parser-engine to display from HTML to XHTML to XML). From a semantical point of view the majority of the tags are poluted/biased by presentational meanings, and under the belief to rescue compatibility the cleanup-forces stick with the majority of the old concepts without attenting new needs. The change in the paradigma: At this point I suggest the complete break with the semantical past. And it's easier than at any time before. There is quasi no software that depends on semantic (except screen-readers, I'm going to talk about that later) as mentioned above. It's time to reflect actual streams in development of HTML; now, with the introduction or the dusk of RIAs the semantic camp got split in three: * metaphorical semantics (the meaning of the things) * structural semantic (the order of the things) * purposal semantics (the purpose of the things) Let me denote some examples: * metaphorical: - joke marks something to be funny, sarcastic or zynic - strong emphasises a content strongly * structural (aka. define dependencies): - p marks text to belong together, to be connected sentences - chapter marks sections to belong together - formular marks an interactive region * purposal: - control marks a region to be inside an interface-element - nav marks a section to contain the/a navigation - title marks a region to be a chapters/documents title In the order written it's sensefull to assume, that metaphorical semantics may be contained by structural elements, and structural elements by purposal elements. Though this doesn't solve the LCD-problem it makes it way more easy as the variety within each LCD-problem becomes less much smaller (for technicians: 2^9 2^3 + 2^3 + 2^3), and it has an elegant fall-back path. The split of responsability and area of application makes it way more easier to meet the needs of: * more metaphorical semantic, which is an inherit need of screen- readers, which is liked to be blamed for being not 'smart' enough * more structural semantic, which
Re: [whatwg] Table integrity and conformance
On Oct 23, 2006, at 21:31, Ian Hickson wrote: I think cells extending (via colspan/rowspan) into columns or rows that contain no cells other than extended cells should be at least a SHOULD NOT, maybe a MUST NOT. Wouldn't it be sufficient and more desirable to require each row to have at least one cell that starts on that row and each column to have at least one cell that starts in that column? (By starts I mean having the top left corner there.) This would allow tables like this: 112 344 and 12 13 43 (Where numbers denote cells so that 11 means a cell spanning two columns.) Browsers don't choke: http://hsivonen.iki.fi/test/wa10/tables/extended-cells.html -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Handling of script elements inside rendered OBJECT
On Wed, 10 May 2006, Shadow2531 wrote:
object type=text/html data=about:blank
scriptalert('You should not see this!');/script
/object
What should happen in situations like that?
The script element is alternate content.
The object is rendered.
The script SHOULD NOT be executed *until* the alernate content is
rendered. (For example, if it's an image, you switch images off and
the alternate content is rendered.)
It makes sense to NOT execute the script in this situation.
However, browsers currently execute the script. (IE6 does not, but
that may be quirky object tag handling.)
The script would be executed straight away. script elements are
executed as soon as they enter the Document DOM, irrespective of where
they are inserted.
(The spec is clear about this now, though some areas still need fleshing
out.)
We basically have to do this because script execution and object
handling are really complicated already, and trying to link them would
only make them even more complicated and lead to hard-to-debug bugs.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Table integrity and conformance
On Wed, 8 Nov 2006, Henri Sivonen wrote: On Oct 23, 2006, at 21:31, Ian Hickson wrote: I think cells extending (via colspan/rowspan) into columns or rows that contain no cells other than extended cells should be at least a SHOULD NOT, maybe a MUST NOT. Wouldn't it be sufficient and more desirable to require each row to have at least one cell that starts on that row and each column to have at least one cell that starts in that column? (By starts I mean having the top left corner there.) This would allow tables like this: 112 344 and 12 13 43 (Where numbers denote cells so that 11 means a cell spanning two columns.) What's the difference? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Test suite: Embedded content
On Tue, 29 Nov 2005, Christian Biesinger wrote: Ian Hickson wrote: Yeah, what's a plugin and what isn't is a UA thing, so if the UA decides that its PNG and SVG plugins happen to be native support, well, that's what it is. (Both PNG and SVG are recognised by Mozilla's embed because at one point they were plugin-only in IE and so people would use embed instead of img/object and so when Mozilla moved to native implemen- tations for those types, it kept embed working for compatiblility.) BTW, Mozilla supports all its image formats in embed. That's allowed, it just means the plugin is the browser itself. How can you drop applet if you want to be compatible with the current web? Much the same way we can drop center: even though it's not valid in HTML5, it doesn't mean browsers won't support it. It's possible that it will be mentioned in the Rendering section (which I don't plan to write until the end of the process). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Table integrity and conformance
On Nov 8, 2006, at 02:59, Ian Hickson wrote: On Wed, 8 Nov 2006, Henri Sivonen wrote: On Oct 23, 2006, at 21:31, Ian Hickson wrote: I think cells extending (via colspan/rowspan) into columns or rows that contain no cells other than extended cells should be at least a SHOULD NOT, maybe a MUST NOT. Wouldn't it be sufficient and more desirable to require each row to have at least one cell that starts on that row and each column to have at least one cell that starts in that column? (By starts I mean having the top left corner there.) This would allow tables like this: 112 344 and 12 13 43 (Where numbers denote cells so that 11 means a cell spanning two columns.) What's the difference? Your formulation seemed to require at least one non-extended (i.e. colspan=1 rowspan=1) cell on each row and column, unless by extending into you didn't mean the row/column on which the cell starts. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
[whatwg] hash Attribute
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 itselfExamples:hash="MD5/9e107d9d372bb6826bd81d3542a419d6"hash="SHA-1/2fd4e1c6 7a2d28fc ed849ee1 bb76e739 1b93eb12"hash="SHA-256/d7a8fbb3 07d78094 69ca9abc b0082e4f 8d5651e4 6d3cdb76 2d02d0bf 37c9e592"See my thread over at mozillaZine for more info and other ideas: http://forums.mozillazine.org/viewtopic.php?p=2234056--Wulf Sponsored Link Talk more and pay less. Vonage can save you up to $300 a year on your phone bill. Sign up now.
Re: [whatwg] hash Attribute
Hello,Aren't URNs already being very commonly used for hashes. For example... urn:sha1:dRDPBgZzTFq7Jl2Q2N/YNghcfj8= urn:md5:FNG4c6MJLdDEY1rcoGb4pQ== urn:kzhash:0bf4c9a50c1058fb6887ad0419ecfc06dc192c69163ea2c45c632dab1cab1e1fbd6fbf1e urn:tiger:tree:ZAJPZOPES4YGIPNHLHDQHD5FHSAFSPIYG7IOO3Y urn:bitprint:QLFYWY2RI5WZCTEP6MJKR5CAFGP7FQ5X.VEKXTRSJPTZJLY2IKG5FQ2TCXK26SECFPP4DX7IPerhaps it would be good to keep with that format. See yaOn 11/7/06, XcomCoolDude [EMAIL PROTECTED] wrote: 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 itselfExamples:hash=MD5/9e107d9d372bb6826bd81d3542a419d6hash=SHA-1/2fd4e1c6 7a2d28fc ed849ee1 bb76e739 1b93eb12 hash=SHA-256/d7a8fbb3 07d78094 69ca9abc b0082e4f 8d5651e4 6d3cdb76 2d02d0bf 37c9e592See my thread over at mozillaZine for more info and other ideas: http://forums.mozillazine.org/viewtopic.php?p=2234056--Wulf -- Charles Iliya Krempeaux, B.Sc.charles @ reptile.casupercanadian @ gmail.comdeveloper weblog: http://ChangeLog.ca/
Re: [whatwg] hash Attribute
Hello,Here's something else related... http://microformats.org/wiki/hash-examplesSee yaOn 11/7/06, Charles Iliya Krempeaux [EMAIL PROTECTED] wrote: Hello,Aren't URNs already being very commonly used for hashes. For example... urn:sha1:dRDPBgZzTFq7Jl2Q2N/YNghcfj8= urn:md5:FNG4c6MJLdDEY1rcoGb4pQ== urn:kzhash:0bf4c9a50c1058fb6887ad0419ecfc06dc192c69163ea2c45c632dab1cab1e1fbd6fbf1e urn:tiger:tree:ZAJPZOPES4YGIPNHLHDQHD5FHSAFSPIYG7IOO3Y urn:bitprint:QLFYWY2RI5WZCTEP6MJKR5CAFGP7FQ5X.VEKXTRSJPTZJLY2IKG5FQ2TCXK26SECFPP4DX7IPerhaps it would be good to keep with that format. See yaOn 11/7/06, XcomCoolDude [EMAIL PROTECTED] wrote: 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 itselfExamples:hash=MD5/9e107d9d372bb6826bd81d3542a419d6hash=SHA-1/2fd4e1c6 7a2d28fc ed849ee1 bb76e739 1b93eb12 hash=SHA-256/d7a8fbb3 07d78094 69ca9abc b0082e4f 8d5651e4 6d3cdb76 2d02d0bf 37c9e592See my thread over at mozillaZine for more info and other ideas: http://forums.mozillazine.org/viewtopic.php?p=2234056--Wulf -- Charles Iliya Krempeaux, B.Sc.charles @ reptile.casupercanadian @ gmail.comdeveloper weblog: http://ChangeLog.ca/ -- Charles Iliya Krempeaux, B.Sc.charles @ reptile.casupercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
Re: [whatwg] hash Attribute
Hello,Also, something else to think about is that, under certain conditions, this info could potentially be passed along via HTTP headers.Maybe something like:HTTP/1.1 200 OKLink: urn:sha1:dRDPBgZzTFq7Jl2Q2N/YNghcfj8=; rel=hashSee yaOn 11/7/06, Charles Iliya Krempeaux [EMAIL PROTECTED] wrote:Hello,Here's something else related... http://microformats.org/wiki/hash-examplesSee ya On 11/7/06, Charles Iliya Krempeaux [EMAIL PROTECTED] wrote: Hello,Aren't URNs already being very commonly used for hashes. For example... urn:sha1:dRDPBgZzTFq7Jl2Q2N/YNghcfj8= urn:md5:FNG4c6MJLdDEY1rcoGb4pQ== urn:kzhash:0bf4c9a50c1058fb6887ad0419ecfc06dc192c69163ea2c45c632dab1cab1e1fbd6fbf1e urn:tiger:tree:ZAJPZOPES4YGIPNHLHDQHD5FHSAFSPIYG7IOO3Y urn:bitprint:QLFYWY2RI5WZCTEP6MJKR5CAFGP7FQ5X.VEKXTRSJPTZJLY2IKG5FQ2TCXK26SECFPP4DX7IPerhaps it would be good to keep with that format. See yaOn 11/7/06, XcomCoolDude [EMAIL PROTECTED] wrote: 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 itselfExamples:hash=MD5/9e107d9d372bb6826bd81d3542a419d6hash=SHA-1/2fd4e1c6 7a2d28fc ed849ee1 bb76e739 1b93eb12 hash=SHA-256/d7a8fbb3 07d78094 69ca9abc b0082e4f 8d5651e4 6d3cdb76 2d02d0bf 37c9e592See my thread over at mozillaZine for more info and other ideas: http://forums.mozillazine.org/viewtopic.php?p=2234056--Wulf -- Charles Iliya Krempeaux, B.Sc.charles @ reptile.casupercanadian @ gmail.comdeveloper weblog: http://ChangeLog.ca/ -- Charles Iliya Krempeaux, B.Sc.charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ -- Charles Iliya Krempeaux, B.Sc.charles @ reptile.casupercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
