search

LeaVerou / animatable

One property, two values, endless possiblities
http://leaverou.github.io/animatable
2.59k stars 659 forks source link

just hyped ... #31

Closed a3lypheboss closed 13 years ago

a3lypheboss commented 13 years ago

just a hyped version with (not much) improvement, but in another coding style according to w3c and whatwg webspec for html 5;

original problems remain: chrome: not using CHECKED-attribute handler, so animations run alltime firefox: a bunch of errors, due to CSS (using linear-gradient directly on background-image-property for example) opera:no operation at all arora: same issue as in chrome

Claudius Raphael Paeth, A3lyphe

every breaking atom living ...

LeaVerou commented 13 years ago

Hi,

There are a couple of issues with your changes:

Thus, I'm closing this pull request.

a3lypheboss commented 13 years ago

Hi Lea,

i want to use this note for a straightforward discussion about the topics we issued yet and i will spend some (more) words on why i do propose it this way:

A word before: I think the w3c is like death to an angel; it has been proven itself as a moloch. about one third to a half of all recommendations are busting nonsense, just showing off that their thoughts are nuts on buts not bolts ...

... and please don't forget, when you read the following, that i've asked you in my first mail for a hint on structuring on github

*[1] UPPERCASE tags, are not given often in the examples, instead they are missed most times, BUT they are explicitly encouraged in the specs, as also the missing quotes are (i talk about the w3c references not the guides); By the way let me add some for a better understanding: I am used and willed to go by xhtml syntax where possible, but through that reason i got some knowledge the last months how browsers react if you mix html5-documents with injected xml or xhtml-snippets, due to the fact that, when you use <!DOCTYPE html> the browser freezes on that doctype and ignores any following header, even if new header is built and sent serverside; you run into this issue anytime you use objects, embeds with mime-type html or x-application or inject via xmlhttprequest; ALL actual graphical browsers don't accept a doctype-change after initial set and load from root-domain.

Now you might say, well, but when will that happen? Once in a million calls ... Sorry, no; anytime you use a loader script, anytime you use a second or more script-tag with src-attribute, anytime you link to more than one style, etc.

The reason why i (and believe me i was struggling for months to do this crap) now propose to use UPPERCASE and no-quotes (especially on src/href-settings) is the fact that in this manner the given problems don't show up.

So let me resume it shorthand:

IF you use <!DOCTYPE HTML> THEN you have to use UPPERCASE-tags and no-quotes for single/chained values BECAUSE any NOT DEFINED in the browser you like so much HTML-5-ELEMENT will let the parser stop rendering default-styles, due to the fact it has to switch to unknown doctype and therefore uses whatever it was preset to in the versions before.

Problem: Any browser is not allowed to accept more than one doctype per document

Can't believe it? Then check it out.

Addition: It is by far more readable and gives you much more possibilities to use these facts to get to a near identical syntax in style,script and structure.

Addition: One thing you are definately wrong with: You used a link-element in xhtml syntax with self-closing slash; that is indeed allowed in the specs, but not accepted by any browser or the syntax-highlighters in editors which parse a document with a given <!DOCTYPE HTML>.

Addition: You should reconsider taking a deeper look into the specs of Unicode; maybe you see why it is even from this point of view, beneficial to use UPPERCASE and no-quote-for-singles

Addition:

*[2] prefix-free is not missing - on restart of chrome animatable runs normally until i run another session of chrome in parallel, which forbids to use the same cached data, because of auto-login in google-accounts on the first window and therefore not-allowing double-logins in 2 different windows, so it is an error of caching (maybe you have noticed that crome agressively restructures loads); In Arora and Safari it runs normally, but has the issue with the wrong reindexing of effects after effect 9.

*[3] Opera does not support CSS animations, like IE? Sorry, you're wrong. It is true that Opera is not allowing many CSS 3 definitions, but there are ways around it (by the way some are the same as for ie); And i have to add, you should take a closer look on dragonfly and compare what it tells you about your scripts and DOM in direct comparison to what Chrome tells you - it's the same, but opera is more harsh about remarking mixing different versions of scripting-syntax; what makes it easier to find a neat way for all platforms, especially if you want to support ie or mobile web-appliances before android

I hope you'll get me right and don't think i want to tell you how you have to do your stuff; It just seems, that you are steadily using chrome and firefox in hope that ie 10 catches up, because you once learned to develop for an ie-build (maybe 7) ;)

However, be sure this isn't in anyway offensive, instead as i told you in my first mail, i just wanted to show you how the main structure has to be written, to AVOID complications in the latest browsers and besides that earning the possibility to make your code downwards-compatible, because what you might not remember because of all the fancy things that are possible now; Sometimes you wish to use the same base for text- or ascii-rendered perspectives of your code, times you wish to generate wap/imode-pages of it, times you wish to make a HtML3 or even 4 or XHtML-Transitive of it ....

and times you just wish to keep it simple and let others learn from your very exciting examples.; which is easier if you diverse xhtml and html notation (i know it is a big fight to agree to that)

I think your way of showing off possibilities is great and i hope you deliver much much more.

Thanks a lot for your great work ...

P.s.: I'm always open for deep-digging-discussions on specific topics or the philosophy of code; if you or any other reader is interested in heavily testing their code by humans not machines, leave me a note.

Thank you for your interest.

Claudius Raphael Paeth, A3lyphe

every breaking atom living ...

LeaVerou commented 13 years ago

And please, try to be more brief. It shows lack of respect in other people's time to write comments that are a thousand words long, especially when they are not even relevant.

yatil commented 13 years ago
  1. Sorry, a3lypheboss, you’re just plain wrong. <!doctype html> just forces the browser into standard mode (compared to quirksmode), as does <!DOCTYPE HTML>, <!dOcTyPe HtMl> and <!DOCtype html>. Upper/lowercase is not relevant at all.
  2. I don’t understand what you mean by “doctype change” after the browser has loaded. The doctype of an element is unchangeable, which is a good thing.
  3. Do you mix HTML5 and XHTML5 differences here? Those only apply when you send out your HTML5 document with an XML mimetype. Mimetypes have nothing to do with doctypes.
  4. Opera doesn’t support CSS animations: http://caniuse.com/#css-animation
  5. Lea’s code is perfectly valid HTML: http://validator.w3.org/check?uri=http%3A%2F%2Fleaverou.github.com%2Fanimatable%2F

And please, try to be more brief. It shows lack of respect in other people's time to write comments that are a thousand words long, especially when they are not even relevant.

I second that.

Daniel15 commented 13 years ago

I don't understand your point about uppercase tags. In HTML4, tags are case-insensitive (see eg. http://www.w3.org/TR/html401/about.html) and in XHTML they must be lowercase, so it makes sense to always use lowercase tags. Even W3Schools knows that tags are case-insensitive. And in fact, I think SGML (which HTML was based on) specifies that tags are case insensitive, too (although I don't have a reference for this).

cookiengineer commented 13 years ago

@Daniel15: Jep, SGML also declares that Elements are case insensitive. See http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2 Well, but it also says that you shouldn't use "<P>" with "</p>" - makes obviously sense.

@a3lypheboss What is the "w3c" reference you are referring to? Nowadays, everything runs through an HTML parser, nothing is parsed in XHTML mode anymore. Look at the WebKit or Firefox source.

poke commented 13 years ago

You should learn to cite things you claim to be true when you try to discuss things based on such “facts”. By doing so, you’ll notice that most of your claims are simply invalid. As others already showed, most of your points are flawed because of your misinterpretion of standards or correlations between things. To not repeat already said things too much, I’ll only comment on a few things that haven’t been addressed yet.

ALL actual graphical browsers don't accept a doctype-change after initial set

The standard does not allow multiple doctype declarations. So if browsers ignore later doctype declarations (that includes multiple declarations, as well as misplaced ones) then that behaviour is perfectly fine. And why should they actually support doctype changes later on? After all, when reading a document, you need to know from the beginning what it is, and can’t change the way you read it later on.

[…] anytime you use a loader script, anytime you use a second or more script-tag with src-attribute, anytime you link to more than one style, etc.

Scripts and stylesheets are not HTML and as such do not have a doctype. As such they especially do not change the current HTML type that is being processed.

IF you use <!DOCTYPE HTML> THEN you have to use UPPERCASE-tags and no-quotes for single/chained values

Browsers do not care about what the doctype is; they only differ between “there is a doctype” (i.e. standards mode) and “there is no doctype” (i.e. quirks mode). As such the casing in the doctype does not matter, apart from what others already said that tags are case insensitive. And if you would like to take a look at the doctype section in the HTML5 standard, then you see that apart from many optional parts btw. it only requires a “case-insensitive match” for the given strings.

[…] You used a link-element in xhtml syntax with self-closing slash; that is […] not accepted by any browser or the syntax-highlighters in editors which parse a document with a given <!DOCTYPE HTML>.

Again, browser do not care about the doctype content; and I’ve never seen a browser fail because of self-closing tags. You might want to proof such claims, except that it won’t be possible to proof it since it’s just wrong. And if your syntax highlighter fails because of a different doctype, you should get a different one (except that nearly all syntax highlighters do not interpret doctypes).

ricardobeat commented 13 years ago

trolololol

thierryk commented 13 years ago

Why not reading comments trying to challenge our own beliefs before rushing to tell people (troll or not) they are plain wrong?

Upper/lowercase is not relevant at all.

Not relevant to the discussion may be, but... Authors willing to write polyglot markup SHOULD use <!DOCTYPE html> (DOCTYPE in uppercase and html in lowercase). See: http://www.w3.org/TR/html-polyglot/#doctype

Browsers do not care about what the doctype is; they only differ between “there is a doctype” (i.e. standards mode) and “there is no doctype” (i.e. quirks mode).

It is not that simple, because they are doctypes that will send some browsers into quirksmode. See: http://hsivonen.iki.fi/doctype/

yatil commented 13 years ago

@thierryk:

Upper/lowercase is not relevant at all. Not relevant to the discussion may be, but... Authors willing to write polyglot markup SHOULD use <!DOCTYPE html> (DOCTYPE in uppercase and html in lowercase). See: http://www.w3.org/TR/html-polyglot/#doctype

Probably that was too short and needs elaboration: “Upper/lowercase is not relevant at all for browser parsing the page.” (Of course roules differ if you want to parse HTML as XML.) http://www.w3.org/TR/html5/syntax.html#the-doctype

In other words, <!DOCTYPE html>, case-insensitively.

thierryk commented 13 years ago

@yatil

In my humble opinion, we should try to author documents for as many parsers as possible. So I'd say it may be best to favor "DOCTYPE" (rather than "doctype") since it gives us XML parsing for free (even though it is just one step in that direction)...

LeaVerou commented 13 years ago

I agree with Thierry about doctype capitalization, but how is that relevant to either the project or a3lypheboss' remarks? a3lypheboss suggested uppercase tags, not just doctypes.

thierryk commented 13 years ago

@Lea

As mentioned earlier, it's not ;-)

I may be wrong, but I don't think there is a valid case for uppercase tags; unless of course a3lypheboss comes up with some serious reference to back up what he said in this thread:

IF you use <!DOCTYPE HTML> THEN you have to use UPPERCASE-tags and no-quotes for single/chained values

a3lypheboss commented 13 years ago

Hi all :) Very amusing (it is positive) to read that heck of comments!

@all: No i don't cite, yet; Because you all are better in that as we can see here and where anyone has pure fear about things that might've been overseen, the ones thinking like that will look for themselves. (But go on i'll cite where necessary)

@LeaVerou: be happy!you all did a very well discussion here. It is no offense, it is just thoughts. But please take time and read on.

@Eric, sry @yatil: i don't think that giving a 1000words or more comment is disrespectful, because as you can see you all probed your thoughts on that and sorry, even if that was my intention, it is not my fault that you could have had better things to be done in that time you spent for checking my thoughts ... ;)

@thierryk, you got what i was trying to profile here.

@ricardobeat: you got it, too! :)

@Daniel15: Go on i'll explain ...

@poke: Go on i'll explain ...

Let me (not in short BUT IN RESPECT) tell you some details (with links and cites):

EXAM: HtML 5 Validation

You want to approve your document for HtML5? Nothing more simple than that! Convert it! ... though this is not actual, but try it out and maybe y'all get a glimpse of what i'm thinking about HtML 5 Validation

http://mynthon.net/tools/xhtml-to-html5/

EXAM: Unicode and Uppercase - what about it

By not just reminiscing what one could have learned programming by using homecomputers first for going over BASIC, Assembler (6502,6510,65k,68k,8068/88),Pascal,Fortran,Cobol,Ada,Lisp,Smalltalk,C,Java,C++,C#, LiveScript, NES, JS,AS, ECMA 5, ... with all the necessities it affords, you may have an idea what knowledge of mnemonics, op-codes and character-tables one can get; Do you? If not, concentrate on the following thoughts (this is for you Lea);

+Unicode.txt -- lookout for the sorting -- ftp://ftp.unicode.org/Public/UNIDATA/UnicodeData.txt

Maybe you get an idea if you read the faq of unicode in comparison to utf-8 definition and classic ASCII especially under aspect of data-, packet- and parity-loss on data-transmissions, with a very special lookout for inconsistent-data, their correction on bond-connections like modem, cable, satellite (which, yeah maybe are not a minority nowadays, what do you think, lea?)

+Unicode-FAQ -- http://www.unicode.org/faq/casemap_charprop.html#3

CITE:

Q: Do all scripts have an uppercase and a lowercase?

A: No, most scripts do not have case. In addition to modern scripts, such as Latin, Greek, Armenian and Cyrillic, a few historic or archaic scripts have case. The vast majority of scripts do not have case distinctions.

Q: Is case folding stable between Unicode versions?

Yes. Beginning with Unicode 5.0, the definition of case folding was stabilized. Any string that is case-folded according to the rules in version 5.0 or later is guaranteed to remain case-folded in any subsequent version of Unicode. One side effect of this is that no new lowercase character will be introduced for an existing upper- or titlecase character that has no lowercase pairing. The reverse is not true: a character that lacks an uppercase mapping or a titlecase mapping could acquire one in some future version.

Note that the stability guarantee only applies to assigned code points. New scripts or characters added to Unicode can include additional case mapping pairs, as long as no existing code point ever changes its lowercase mapping. That is, when encoding a new script, a new lowercase letter might be introduced for an uppercase character introduced at the same time. For additional stability guarantees, see the Unicode Character Encoding Stability Policy.

REST:

This concludes that clear-text, so text that is not declared as purely-machine-readable, instead undefined in its mapping or folding in general jumps back to its lowercase ... but Lea, we talk about tags for elements, which should be clearly readable by both, human (if coder or equivalent) AND MACHINE (so a steady choice for what is for the machine and what is for both, might be worth to think about) and to give another argument on the difference between xhtml and html, because Daniel15 stated:

"I don't understand your point about uppercase tags. In HTML4, tags are case-insensitive (see eg. http://www.w3.org/TR/html401/about.html) and in XHTML they must be lowercase, so it makes sense to always use lowercase tags. Even W3Schools knows that tags are case-insensitive. And in fact, I think SGML (which HTML was based on) specifies that tags are case insensitive, too (although I don't have a reference for this)."

Right- in XHTML tags HAVE TO BE lowercase, that means its counterfeit HTML should be clearly marked as NOT BEING XHTML, so we HAVE TO USE UPPERCASE for HTML, to make it machine- and human-readable as such.

And to get back with one more issue on upper- and lowercase-settings according to my note on data-corruption while transmission, what kind of text can be restored easier by comparing with lexical libraries given if the DOCTYPE is set to undefined but anything html like in doubt? any variant? or maybe if the writing leans on well kwown schemes like using UPPERCASE-tags for HTML and lowercase-tags for XHTML?

Another thing is data-compression; maybe you should compare yourself the compression-ratios for UPPERCASE-markup.

Another issue is using uppercase for boolean-attributes like CHECKED, ASYNC or DEFER

Remember: uppercase becomes lowercase the moment it WAS parsed, but it IS lowercase as long as it WAS NOT (interesting fact if you try to follow dom-manipulations in asynchronous or worker-scripts or if you ever visualized what happens when you create an object/embed or iframe-element on the fly.

However, there is many many more which is useful to us if we would respect it as a base for how sources are parsed: by machine AND by human.

@Lea you said you need a reference to the reference, where it says what i said: ... that we are encouraged to use UPPERCASE and NOQUOTES

well nothing more simple if you first agree that ENCOURAGING means making someone doing some in a specific manner because of a (logical) conclusion or for securement -- ENFORCING instead would be have-to-do:

The DOCTYPE originates from HTML’s SGML lineage and, in previous levels of HTML, was originally used to refer to a Document Type Definition (DTD) — a formal declaration of the elements, attributes and syntactic features that could be used within the document. Those who are familiar with previous levels of HTML will notice that there is no PUBLIC identifier present in this DOCTYPE, which were used to refer to the DTD. Also, note that the about: URI scheme in the SYSTEM identifier of the latter DOCTYPE is used specifically because it cannot be resolved to any specific DTD.

As HTML5 is no longer formally based upon SGML, the DOCTYPE no longer serves this purpose, and thus no longer needs to refer to a DTD. However, due to legacy constraints, it has gained another very important purpose: triggering no-quirks mode in browsers.

"HTML 5 defines three modes: quirks mode, limited quirks mode and no quirks mode, of which only the latter is considered conforming to use. The reason for this is due to backwards compatibility. The important thing to understand is that there are some differences in the way documents are visually rendered in each of the modes; and to ensure the most standards compliant rendering, it is important to ensure no-quirks mode is used."

"In XHTML, tag names are case sensitive and are usually defined to be written in lowercase. In HTML, however, tag names are case insensitive and may be written in all uppercase or mixed case, although the most common convention is to stick with lowercase. The case of the start and end tags do not have to be the same, but being consistent does make the code look cleaner."

"In XHTML, attribute names are case sensitive and most are defined to be lowercase. In HTML, attribute names are case insensitive, and so they could be written in all uppercase or mixed case, depending on your own preferences. It is conventional, however, to use the same case as would be used in XHTML, which is generally all lowercase."

"In HTML, but not in XHTML, the quotes surrounding the value may also be omitted in most cases. The value may contain any characters except for spaces, single or double quotes (' or "), an equals sign (=) or a greater-than symbol (>). If you need an attribute to contain those characters, they either need to be escaped using character references, or you need to use either the single- or double-quoted attribute values."

Just to show the most simple ones that can lead to the necessary conclusion that using UPPERCASE to differ HTML from XHTML and robust the attribute-handling.

By the way, it is from W3C's Editor Draft for HTML 5

Just another thing, because there was some discussion about DOCTYPE

http://www.w3.org/TR/2011/WD-html5-author-20110809/syntax.html#syntax

Please read carefully and think about what i told about ASCII and case-mapping in UNICODE

Effectively we can resume:

UPPERCASE-TAGS

By the way, let me ask this: Why do y'all fight for your freedom to write your HTML in xhtml-style, but on the other hand proclaim to write PURE HTML 5? Wouldn't it be cooler to show off, that you know the difference and can show off your consumers and clients that HTML 5 is NOT XHTML, XML whatever? Or did i miss some point, e.g. marketing-strategies? However, you should think about it ...

One last call @poke, you wrote on my "ALL actual graphical browsers don't accept a doctype-change after initial set" : "The standard does not allow multiple doctype declarations. So if browsers ignore later doctype declarations (that includes multiple declarations, as well as misplaced ones) then that behaviour is perfectly fine. And why should they actually support doctype changes later on? After all, when reading a document, you need to know from the beginning what it is, and can’t change the way you read it later on."

Poke, Lea and Eric; You forget about one thing: When you read a html-document via XMLHttpRequest as HtML or if you create an element with a src or href runtime then the browser (in some cases might, in most) will parse the loaded/linked document as html, to be specific as the doctype given, which means no-quirks-mode for DOCTYPE html or DOCTYPE HTML; the parser assumes that the content loaded is written under the same rules, BUT if you set a specific doctype in the external document, you can ensure that a browser that is able to parse in background reads external xhtml as such for example; This thought the other way round: If you DOCTYPE your root document to HTML you can not load an external html-nodetree where void-elements like META and LINK are set or STYLEs or SCRIPTs, which are defined to other languages then those that the browser presets when finding your first DOCTYPE html; any language or type -attribute in an external document has to be ignored, which leads to a simple but for some people annoying effect:

Anything loaded afterwards has to be compatible with the given rule-set delivered by the browser on init of the root-document, which was DOCTYPE HTML

Before anyone of you feels angry about the length of my comment, please think about what you have to say, because even if it is not the appropriate place to discuss such thoughts, it seems the interest in it is there, or not?

I thank you all very much for your participation on this (maybe times too philosophical) discussion i started, but i have a reason for why i did it here.

I think Lea has build a very very nice example of how code can show finesse in its structure and how it handles vendor-specific idioms and terms to gain a simple enough, yet extensible micro-framework for a specific task.

It is small enough to be easily understood by pros as well as newbies and it could be a perfect example for pushing semantics back into the webwork, so that anyone can learn from it.

You did very good work, Lea; Thanks for that.

I have the hope you all find time (whenever) to rethink about the issues, by looking for yourself what is right and what is wrong, or to say it plain:

Keep track and come back.

Thanks.

Claudius Raphael Paeth, A3lyphe

every breaking atom living ...

EDIT: @Lea: Opera: -o-

@all: I am editing the animatable.git and the prefixfree.git at the moment; I'll commit the edits on my a3lypheboss-forks tonight; look out for the branch HYPE if you wanna know, what i mean when i'm talking about 'correct annotatable syntax for pros and newbs'; maybe you find some more answers and questions to the given topics; I'll also checkout the line-comment feature of github after that, just to make my own experience with it and in the hope it will be easier to follow why and how i change stuff, without changing neither content nor its representation, but making it more compatible, editable and easier to learn and understand. PLEASE DON'T FORGET: I am just doing this under aspect of edit- and read-ability by HUMANS AND MACHINES. It is NOT a BETTER way, it is just ANOTHER WAY of doing things.

Thanks again to all of you interested in it.

Good luck brothers and sisters ... ;)