Re: [whatwg] additional key attribute in form field

[carmen]

> > i wonder why there's still no a special 'key' attribute for every form
> > field implemented.

> 1. Your code is old-fashioned

old-fashioned or not, the reality is most popular web frameworks are using 
regex hacks on the name field to squish more information in there.



it might be worth considering how they could use normal form fields without 
Javascript, and not require Regex in multiple places along the line. obviously 
another workaroudn besides regex is custom serialization and nonstandard 
attribute names of the input element - my preference using RDFa style 
predicates to describe what the field actually contains...


the idea is making the baseline form field not require hacks..

Re: [whatwg] The issue of interoperability of the element

[carmen]

> But I don't accept that idealistic advocacy regarding encoding format
> support for the  element is pointless in the situation in which
> we are today where the market leaders haven't yet decided what they are
> going to do.

they havent? it seems pretty clear to me

adobe - push swf/flv/apollo
microsoft - push windowsmedia/silverlight
apple - push quicktime/h26[34]

due to installed-base LCD, we're stuck with flv unless:
 microsoft<>apple agree on a codec, or
 webkit<>mozilla<>opera agree on a codec and IE has to cave in and support it 
too

has any player shown recent interest in change?

Re: [whatwg] Attributes vs. Elements

[carmen]

> Finally, I'd like to conclude with this reductio ad absurdum of the XHTML2 
> approach. If assigning behavior and semantics to attributes is so much 
> better, why not just have a single  element:
> 
> My cat is really cute: picture of 
> my cat. Check out this  role="emphasis">hilarious story about her.


this is a valid approach. the next step is to factor out  and simplify the 
syntax, preferably reusing JSON or the Relax-NG compact syntax. then it would 
be more readable than either suggestion here. 

i also think its important that userdefined elements can inherit from other 
elements via the normal ECMAscript prototype idioms, so that one can eg, 
.property("dc:date").prototype = , we'll always have semantic 
ambiguity and shoehorning of semantics into classnames and other attributes 
until theres the equivalent of the stylesheet providing referencable URIs 
describing any element - unless we want to stick to the boring world where 
theres only the elements that enough people could agree upon.

styling all the 'time' elements in the stylesheet is cake.. easier than 
deconstructing a microformat, or having to resort to crazy attribute matching 
xpath/regex..

fwiw, ive started doing this using HPricot serverside and JQuery clientside 
since i found microformats too limiting and both them and RDFa too verbose 
(they use attributes quite a bit instead of elements), i started writing 
webpages in pico and will do what it takes for that to continue in the day and 
age where i want semantic disambiguity/lossless-encoding for the elements.

> I find the HTML approach much more readable and more semantically clear:
> 
> My cat is really cute: . 
> Check out this hilarious story about 
> her.
> 
> Regards,
> Maciej
> 

Re: [whatwg] canvas elements etc

[carmen]

On Sun Mar 11, 2007 at 05:06:06PM -0400, Matthew Raymond wrote:
> carmen wrote:
> >  are there plans to support html style creation of elements within the
>  tag?
> 
>How would that be different from Scalable Vector Graphics (SVG)???

thats kind of what i'm asking, it looks like SVG has its own API already, sort 
of similar to canvas. are there plans to merge? can you use svg elements inwide 
a canvas element or will the browser not find them? are there plans for that to 
change? etc.

i guess a roadmap explaining the relationship between  and .. is 
this another xhtml2 vs html5, simultaneous development? what was wrong with SVG 
that required a simpler replacement (but i guess not element level interface).. 

anyways, i guess i'lll scour faqs and unsubscribe

> 

Re: [whatwg] href attribute

[carmen]

On Sun Mar 11, 2007 at 09:30:58PM +0100, Anne van Kesteren wrote:
> On Sun, 11 Mar 2007 21:27:14 +0100, carmen <[EMAIL PROTECTED]> wrote:
> >suppose one is building a GUI with solely  elements. say you have a 
> >doorway, clicking on it opens into the room, which is another page. forcing 
> >this stuff into onclick() just because href= 
> >is invalid, decreases scrapability/accessibility. is one supposed to just 
> >wrap canvas polygons in s or something?
> 
> What does ... not offer that  href="">... does? And if this is in fact an application you might 
> actually want to have the  as fallback of the 

well i was thinking like . i guess its not that simple yet..

>  along with other content...
> 
> 
> --
> Anne van Kesteren
> <http://annevankesteren.nl/>
> <http://www.opera.com/>
> 

Re: [whatwg] canvas elements etc

[carmen]

> suppose one is building a GUI with solely  elements.

i suppose i should have researched   - it looks like it doesn't have 
elemnts one might be faimilar with the Tk canvas - you can only draw using 
javascript. are there plans to support html style creation of elements within 
the  tag?

Re: [whatwg] href attribute

[carmen]

On Sun Mar 11, 2007 at 08:52:36PM +0100, Anne van Kesteren wrote:
> On Sun, 11 Mar 2007 06:03:02 +0100, Daniel Glazman <[EMAIL PROTECTED]> wrote:
> >>In any case not all 's are hyperlinks so for your meaning of semantic 
> >>they should also not be automatically hyperlinks (or anchors if you wish). 
> >>I am pretty sure that existence of 'href' 
> >>attribute is what creates semantic meaning of  for you. So why  
> >>cannot be  or ?
> >
> >Let me also play the devil (I love it) : a feature is not trashable
> >only because it comes from XHTML 2.0 :-)
> 
> I agree. One of the reasons HTML5 has  and redefined -.
> 
> 
> >Here, a global href is a really cool idea, we should have done it in
> >HTML 4 but we were too blind to see.
> 
> What are the problems it solves? To my mind introducing it will just break 
> compatibility and complicate implementations for no apparent benefit. You 
> also get to deal with silly cases like:

suppose one is building a GUI with solely  elements. say you have a 
doorway, clicking on it opens into the room, which is another page. forcing 
this stuff into onclick() just because href= is invalid, decreases 
scrapability/accessibility. is one supposed to just wrap canvas polygons in 
s or something?

> 
>   http://www.opera.com/>
> 
> 
> HTML5 already redefines  to be hyperlink or a placeholder for one (this 
> should address your concern raised in another e-mail). The idea of  name=""> is not mentioned in the draft and isn't even 
> conforming (although I suppose user agents will be required to support it). 
> Any element can be a link target much like in HTML4.
> 
> 
> --
> Anne van Kesteren
> 
> 
> 

Re: [whatwg] href attribute

[carmen]

On Sun Mar 11, 2007 at 06:03:02AM +0100, Daniel Glazman wrote:
> On 11/03/2007 05:59, Andrew Fedoniouk wrote:
> 
> >In any case not all 's are hyperlinks so for your meaning of semantic 
> >they should also not be automatically hyperlinks (or anchors if you wish). I 
> >am pretty sure that existence of 'href' 
> >attribute is what creates semantic meaning of  for you. So why  cannot 
> >be  or ?
> 
> Let me also play the devil (I love it) : a feature is not trashable
> only because it comes from XHTML 2.0 :-)

wow, thanks for pointing that out... i had no idea. at least if i start doing 
it i can prove someone else thought it was a good enough idea to put in 
writing..

[1] http://www.w3.org/TR/xhtml2/mod-hyperAttributes.html




> Here, a global href is a really cool idea, we should have done it in
> HTML 4 but we were too blind to see.
> 
> 
> 

Re: [whatwg] element proposal

[carmen]

> Like some previous posters I also think that only a few  formats (or even 
> just one) should be supported by the 
>  tag. I specifically think that we should let the proprietary formats 
> live on in the  world. But it 
> may be difficult to prevent proprietary formats to slip over to .

 especially when the obvious choice for backend implementation , ffmpeg, 
already has reverse engineered support of realmedia, windows media, and flash 
video. and supports the h264 that quicktime uses these days..

i wholeheartedly suport everything said so far. video on the web is getting 
worse and worse. back in 1995, most things played fine, since they were .mpg 
and all the plugins suported it. nowadays, i cant even find a grasemonkey 
script to turn an brightcove embed into a mplayer/vlc-plugin compatible embed, 
even tho brightcove content is spreading across the net like a virus..

that, and greasemonkey doesnt work right in minefield, and theres no flash for 
64bit OSes. so im pretty much shit out from every video on the net..

which isnt a bad thing, but 50% of pages have big broken plugin boxes in them 
these days :/

Re: [whatwg] href attribute

[carmen]

On Fri Mar 02, 2007 at 08:09:10PM +0100, David Håsäther wrote:
> Colin Lieberman wrote:
> 
> >I don't see the href attribute specified anywhere but the a element in the 
> >current Web Applications spec. Is there interest in expanding actionable 
> >elements in this way?

definitely, as it facilitates the DRY principle of not repeating tags just to 
fulfll the browser's wishes of only having the href attribute on certain tags..

> 
> No, as this would not be backwards-compatible.

instead of the generic 'no'. can you implicate situations where a href tag on a 
non-'a' element confuses the browser?

> 
> --
> David Håsäther
> 

Re: [whatwg] [WF3] Web Forms 3.0 Feature List

[carmen]

> |   
> |   [...] /
> |   [...]

don't you see cc1_exp_year as a bit of a problem? i hope webforms3 addresses 
the name hacking that has become standard in web frameworks to flatten multiple 
db tables, columns, keys, usernames, records, etc into a single name field. 
requiring regex is not so cool..