blade ui notes
john
> functionality.
i agree with you about the appeal of the white background. but i think
the difference between pages that cause stuff to change and pages that
just list stuff will be a useful one given enough time to breed
familiarity.
> Probably just me being too used to the old way and I'll have to just
> get over it. Sorry to be a spoilsport!
it's definitely not just you. here's my best guess about why it's
bugging me. despite being in favor of the concept behind it.
in existing page edit ui nearly all elements have nearly equal tone
(i.e. monotone); whereas in the blade ui the background is dark with
bright elements really popping out which tend to cause my eye to
wander around the page looking at all the interesting details these
bright spots highlight instead of focusing on the content of the page
i'm editing. i suppose that could be the newness factor to some extent
but i'm not sure it 100% to blame; i always liked the lack of
decorations in the admin ui.
i think the issue maybe this is too much visual distinction to make
too little of a mental distinction. possibly a lighter gray would help
restore some monotony while keeping all the nice details that have
been added.
while we're on the subject of the blade ui here are some notes i've
made over the last couple of weeks of trying it out...
the bad:
some of these are long standing but continue in blade and i'm only
starting with the bad so the end can be positive :)
* still no "available tags" documentation in the snippets or layouts.
i usually end up with a browser window devoted to and sized to fit the
available tags popup; even when i'm on pages and could pop it up it
seems less helpful after it's obscuring the textarea. maybe the in
page popup could have an option to pop-out into a dedicated window
like chat in gmail does.
* why introduce a settings tab that doesn't compete with (or replace)
the settings extension? is the plan to add more stuff in there that
would replace the settings extension?
* still too many headings for my taste, e.g. Design > Layouts > Layout
(guess it's better than Layouts > Layouts > Layout). i can tell from
Design > Layouts and a list of named layouts that those things in the
list are layouts. if it's for accessibility maybe adding display:none
to the visual stylesheet would be a good compromise.
* heading inconsistency, compare the style of headings on Settings >
Personal to any other page. i prefer the Settings > Personal style at
least in that style the 3rd heading is not just the singular of the
2nd heading (although as i said before i could do without the 3rd
headings completely).
* continued use of "Context-Type" in layout instead of "Content-Type"
which is what the content of that field (almost) always is. so why not
reuse terminology developers are probably familiar with and people who
aren't can at least easily google? could it just be a long standing
typo in radiant?
* "Metadata" in layouts doesn't seem like the right word for "Context-
Type" or "Content-Type"
* the "New Snippet" and "New Layout" buttons are now way down at the
bottom meaning i have to move the mouse to the top to click snippets
then drag my mouse all the way to the bottom to click new snippet the
have to immediately drag it all the way back to the top when i want to
fill the in the name of my new snippet. not sure the current ui (which
changes the button location after every add/remove) does much better
overall but it will at least require less mouse movement than blade
until you get an entire screen filled top to bottom with snippets/
layouts. i didn't test what happens in blade with that many snippets
or layouts is it fixed to the bottom or will it start to move down
eventually?
the inconsequential:
(feel free to skip to "the good" from here these things are truly
unimportant)
* still "admin.title - admin.subtitle" for every <title>. with how
little space there is in a tab for a meaningful title i'd like
something that helps me find it faster in the list of tabs. maybe
"action title: admin.title - admin.subtitle" e.g. "Edit Homepage:
Radiant CMS - Publishing..."
* still 11 network request just for the javascript. is there something
about the way the admin js works that makes it hard or irritating to
have them concatenated? imagine a user (shouldn't be hard) who doesn't
have caching or compression setup properly and has to constantly
download 200k in 11 files (from the bargain basement hosting service)
just to make a minor edit to the site.
* i still don't agree with the choice of doctype. willfully triggering
almost standards mode is almost always wrong. you should do it when:
1) you are using photoshop to slice up images and jam them into a
table based layout (or some similar bad practice) and you are going to
be serving that to new browsers as well as old browsers such as mac
ie5, ie6/7 and opera 7 __and__ 2) you want the new browsers to act
like old ones such as mac ie5, ie6/7 and opera 7. `<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/
DTD/xhtml1-strict.dtd">` is an option although `<!DOCTYPE html>` would
trigger equivalent behavior in browsers. i know this is a mostly
pedantic since radiant doesn't even use the non-standard table cell
handling feature almost standards mode triggers but does this bother
anyone else? (and not even using the one feature you get by invoking
this "bastard" rendering mode makes it an even more questionable
decision to me)
the good:
* glad to see the removal of the admin title/subtitle/footer it's
always been a waste of space.
* gone is the flash message that makes the ui jump around. i have a
feeling it may be coming back at some point so i beg you to reconsider
the jumping behavior; it's the worst part of the current ui. make it
stick to top or bottom (or middle) of the screen; anything but
suddenly and drastically affecting the layout. even a javascript alert
would be better than feeling nervous about having the thing you were
about to click jump out from under your click.
* the change password ui is a nice touch. i've had a couple of clients
ask why they have to change their password when they update their
email address (which i always ask them to do once the site launches).
* i prefer the content/design vs. pages/snippets/layouts although i'd
put snippets in design and only pages in content. i can see why
developers consider snippets as content but to me it still feels more
like the content you'd find in a layout except that you might not want
the snippet content on every page. i remove all tabs (even the pages
tab) from the interface for clients then build the site in such a way
that they never need consider anything outside the content of the page
they want to edit. i've hacked extra buttons on to the textile_editor
a couple of times to provide one click access to insert 1 or 2
snippets that they might need but i never said the word "snippet" to
anyone and those were exceptions to the rule. maybe it's that approach
that tends to lump snippets and layouts together and i could be alone
there.
* the url on the view site button makes me think it's going to be a
popup. i hope that's the case but why the #view_site_popup url instead
of just target=_blank is it going to open an iframe in the admin ui or
something? i'd prefer target=_blank to an iframe since an iframe would
have essentially the same problem you already have where "view site"
is more accurately "switch to site view" or something where switch is
the important part. i want "view site" to mean "open a new window (or
tab) with the site view" where new is the important part. as a bonus
with target=_blank it's up to me and my browser whether that means
open a new window/tab on top of or behind the current one both are
useful.
John W. Long
I don't have time to respond to all of this tonight, but you did point
out some things that were helpful. Some of them are things that we
were aware of, some are things we are thinking about, and some, like
"Context-Type" were just plain errors. Of course I'm not in total
agreement on everything, but I hope to respond in detail soon.
I just committed a couple of changes. Have a look at the commit log on
Github.
--
John Long
http://wiseheartdesign.com
John W. Long
> in existing page edit ui nearly all elements have nearly equal tone
> (i.e. monotone); whereas in the blade ui the background is dark with
> bright elements really popping out which tend to cause my eye to
> wander around the page looking at all the interesting details these
> bright spots highlight instead of focusing on the content of the page
> i'm editing. i suppose that could be the newness factor to some extent
> but i'm not sure it 100% to blame; i always liked the lack of
> decorations in the admin ui.
>
> i think the issue maybe this is too much visual distinction to make
> too little of a mental distinction. possibly a lighter gray would help
> restore some monotony while keeping all the nice details that have
> been added.
immediately. There are other things that I think deserve more priority
before I take another pass at the general look and feel. However, that
shouldn't stop someone that feels passionately about this from
experimenting with their own fork of the prototype.
> * still no "available tags" documentation in the snippets or layouts.
> i usually end up with a browser window devoted to and sized to fit the
> available tags popup; even when i'm on pages and could pop it up it
> seems less helpful after it's obscuring the textarea. maybe the in
> page popup could have an option to pop-out into a dedicated window
> like chat in gmail does.
open to making it detachable. If you have time to investigate please
fork the prototype explore the idea.
> * why introduce a settings tab that doesn't compete with (or replace)
> the settings extension? is the plan to add more stuff in there that
> would replace the settings extension?
distribution. Also, I've got a bit of a different idea about how this
should be implemented than the way the settings extension did it.
> * still too many headings for my taste, e.g. Design > Layouts > Layout
> (guess it's better than Layouts > Layouts > Layout). i can tell from
> Design > Layouts and a list of named layouts that those things in the
> list are layouts. if it's for accessibility maybe adding display:none
> to the visual stylesheet would be a good compromise.
Our hope is that the extra level of navigation will make it easier for
extensions to extend the interface without bloating it with tabs when
you have too many installed. I'm definitely interested in what other
people think about this change. Do you have ideas for making this
better in some way?
> * heading inconsistency, compare the style of headings on Settings >
> Personal to any other page. i prefer the Settings > Personal style at
> least in that style the 3rd heading is not just the singular of the
> 2nd heading (although as i said before i could do without the 3rd
> headings completely).
post a screenshot of what you mean and explain why it is inconsistent?
> * continued use of "Context-Type" in layout instead of "Content-Type"
> which is what the content of that field (almost) always is. so why not
> reuse terminology developers are probably familiar with and people who
> aren't can at least easily google? could it just be a long standing
> typo in radiant?
> * "Metadata" in layouts doesn't seem like the right word for "Context-
> Type" or "Content-Type"
metadata section. At present we have changed the link to More/Hide.
> * the "New Snippet" and "New Layout" buttons are now way down at the
> bottom meaning i have to move the mouse to the top to click snippets
> then drag my mouse all the way to the bottom to click new snippet the
> have to immediately drag it all the way back to the top when i want to
> fill the in the name of my new snippet. not sure the current ui (which
> changes the button location after every add/remove) does much better
> overall but it will at least require less mouse movement than blade
> until you get an entire screen filled top to bottom with snippets/
> layouts. i didn't test what happens in blade with that many snippets
> or layouts is it fixed to the bottom or will it start to move down
> eventually?
> the inconsequential:
>
> (feel free to skip to "the good" from here these things are truly
> unimportant)
>
> * still "admin.title - admin.subtitle" for every <title>. with how
> little space there is in a tab for a meaningful title i'd like
> something that helps me find it faster in the list of tabs. maybe
> "action title: admin.title - admin.subtitle" e.g. "Edit Homepage:
> Radiant CMS - Publishing..."
> * still 11 network request just for the javascript. is there something
> about the way the admin js works that makes it hard or irritating to
> have them concatenated? imagine a user (shouldn't be hard) who doesn't
> have caching or compression setup properly and has to constantly
> download 200k in 11 files (from the bargain basement hosting service)
> just to make a minor edit to the site.
but I would love to see this fixed as well.
> * i still don't agree with the choice of doctype. willfully triggering
> almost standards mode is almost always wrong. you should do it when:
> 1) you are using photoshop to slice up images and jam them into a
> table based layout (or some similar bad practice) and you are going to
> be serving that to new browsers as well as old browsers such as mac
> ie5, ie6/7 and opera 7 __and__ 2) you want the new browsers to act
> like old ones such as mac ie5, ie6/7 and opera 7. `<!DOCTYPE html
> PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/
> DTD/xhtml1-strict.dtd">` is an option although `<!DOCTYPE html>` would
> trigger equivalent behavior in browsers. i know this is a mostly
> pedantic since radiant doesn't even use the non-standard table cell
> handling feature almost standards mode triggers but does this bother
> anyone else? (and not even using the one feature you get by invoking
> this "bastard" rendering mode makes it an even more questionable
> decision to me)
explanation? I'm not sure that I understand what we are doing wrong
and why it upsets you.
> the good:
> * gone is the flash message that makes the ui jump around. i have a
> feeling it may be coming back at some point so i beg you to reconsider
> the jumping behavior; it's the worst part of the current ui. make it
> stick to top or bottom (or middle) of the screen; anything but
> suddenly and drastically affecting the layout. even a javascript alert
> would be better than feeling nervous about having the thing you were
> about to click jump out from under your click.
place that it is still used is when there are errors on the form. I
don't like it when they disappear though. Sean can we change this back
to the old behavior?
> * the change password ui is a nice touch. i've had a couple of clients
> ask why they have to change their password when they update their
> email address (which i always ask them to do once the site launches).
near future too.
> * i prefer the content/design vs. pages/snippets/layouts although i'd
> put snippets in design and only pages in content. i can see why
> developers consider snippets as content but to me it still feels more
> like the content you'd find in a layout except that you might not want
> the snippet content on every page. i remove all tabs (even the pages
> tab) from the interface for clients then build the site in such a way
> that they never need consider anything outside the content of the page
> they want to edit. i've hacked extra buttons on to the textile_editor
> a couple of times to provide one click access to insert 1 or 2
> snippets that they might need but i never said the word "snippet" to
> anyone and those were exceptions to the rule. maybe it's that approach
> that tends to lump snippets and layouts together and i could be alone
> there.
places. Does anyone else feel strongly about this?
> * the url on the view site button makes me think it's going to be a
> popup. i hope that's the case but why the #view_site_popup url instead
> of just target=_blank is it going to open an iframe in the admin ui or
> something? i'd prefer target=_blank to an iframe since an iframe would
> have essentially the same problem you already have where "view site"
> is more accurately "switch to site view" or something where switch is
> the important part. i want "view site" to mean "open a new window (or
> tab) with the site view" where new is the important part. as a bonus
> with target=_blank it's up to me and my browser whether that means
> open a new window/tab on top of or behind the current one both are
> useful.
not sure about the target=_blank suggestion. Part of me feels that it
should be left up to the user. After all, the user can Control/Command
+click a link to get it to open in another window/tab.
john muhl
>
> On Sep 15, 5:43 pm, john <johnm...@gmail.com> wrote:
>> in existing page edit ui nearly all elements have nearly equal tone
>> (i.e. monotone); whereas in the blade ui the background is dark with
>> bright elements really popping out which tend to cause my eye to
>> wander around the page looking at all the interesting details these
>> bright spots highlight instead of focusing on the content of the page
>> i'm editing. i suppose that could be the newness factor to some extent
>> but i'm not sure it 100% to blame; i always liked the lack of
>> decorations in the admin ui.
>>
>> i think the issue maybe this is too much visual distinction to make
>> too little of a mental distinction. possibly a lighter gray would help
>> restore some monotony while keeping all the nice details that have
>> been added.
>
> Great observations. Probably not something that I will address
> immediately. There are other things that I think deserve more priority
> before I take another pass at the general look and feel. However, that
> shouldn't stop someone that feels passionately about this from
> experimenting with their own fork of the prototype.
in that case i'll find some time this week to do some experimenting.
>> * still no "available tags" documentation in the snippets or layouts.
>> i usually end up with a browser window devoted to and sized to fit the
>> available tags popup; even when i'm on pages and could pop it up it
>> seems less helpful after it's obscuring the textarea. maybe the in
>> page popup could have an option to pop-out into a dedicated window
>> like chat in gmail does.
>
> I'd like to see available tags on snippets and layouts too. And I'm
> open to making it detachable. If you have time to investigate please
> fork the prototype explore the idea.
i'll see what i can work up.
>> * why introduce a settings tab that doesn't compete with (or replace)
>> the settings extension? is the plan to add more stuff in there that
>> would replace the settings extension?
>
> The goal is to have a standard way of doing this in the core
> distribution. Also, I've got a bit of a different idea about how this
> should be implemented than the way the settings extension did it.
i'm certainly not married to the settings extension; especially if
something to replace it is baked in. one less extension to install
always sounds good.
>> * still too many headings for my taste, e.g. Design > Layouts > Layout
>> (guess it's better than Layouts > Layouts > Layout). i can tell from
>> Design > Layouts and a list of named layouts that those things in the
>> list are layouts. if it's for accessibility maybe adding display:none
>> to the visual stylesheet would be a good compromise.
>
> Do you mean that it takes too many clicks to get from place to place?
> Our hope is that the extra level of navigation will make it easier for
> extensions to extend the interface without bloating it with tabs when
> you have too many installed. I'm definitely interested in what other
> people think about this change. Do you have ideas for making this
> better in some way?
no i just meant that the 3rd heading isn't really necessary. the
Content > Pages headings already tell you everything; "Pages" just
takes up space.
http://skitch.com/johnmuhl/b9ub7/radiant-cms-publishing-for-small-teams
>> * heading inconsistency, compare the style of headings on Settings >
>> Personal to any other page. i prefer the Settings > Personal style at
>> least in that style the 3rd heading is not just the singular of the
>> 2nd heading (although as i said before i could do without the 3rd
>> headings completely).
>
> I'm not sure that I understand what you are referring to here. Can you
> post a screenshot of what you mean and explain why it is inconsistent?
http://skitch.com/johnmuhl/b9ung/radiant-cms-publishing-for-small-teams
>> * "Metadata" in layouts doesn't seem like the right word for "Context-
>> Type" or "Content-Type"
>
> We are presently exploring the idea of changing the name of the
> metadata section. At present we have changed the link to More/Hide.
i like that better than more/less or metadate/hide. maybe details/hide.
>> * the "New Snippet" and "New Layout" buttons are now way down at the
>> bottom meaning i have to move the mouse to the top to click snippets
>> then drag my mouse all the way to the bottom to click new snippet the
>> have to immediately drag it all the way back to the top when i want to
>> fill the in the name of my new snippet. not sure the current ui (which
>> changes the button location after every add/remove) does much better
>> overall but it will at least require less mouse movement than blade
>> until you get an entire screen filled top to bottom with snippets/
>> layouts. i didn't test what happens in blade with that many snippets
>> or layouts is it fixed to the bottom or will it start to move down
>> eventually?
>
> It's fixed to the bottom.
cool. that'll make the muscle memory part much easier.
>> the inconsequential:
>>
>> (feel free to skip to "the good" from here these things are truly
>> unimportant)
>>
>> * still "admin.title - admin.subtitle" for every <title>. with how
>> little space there is in a tab for a meaningful title i'd like
>> something that helps me find it faster in the list of tabs. maybe
>> "action title: admin.title - admin.subtitle" e.g. "Edit Homepage:
>> Radiant CMS - Publishing..."
>
> That's a good suggestion. I would definitely consider a pull request.
it's on my list then.
>> * still 11 network request just for the javascript. is there something
>> about the way the admin js works that makes it hard or irritating to
>> have them concatenated? imagine a user (shouldn't be hard) who doesn't
>> have caching or compression setup properly and has to constantly
>> download 200k in 11 files (from the bargain basement hosting service)
>> just to make a minor edit to the site.
>
> The complicated part is that extensions can add their own Javascripts,
> but I would love to see this fixed as well.
i'd be fine with just having the core js concatenated and letting
extensions add additional requests. i hardly ever have 10 extensions
loaded on a production site so it'd still be a net gain.
>> * i still don't agree with the choice of doctype. willfully triggering
>> almost standards mode is almost always wrong. you should do it when:
>> 1) you are using photoshop to slice up images and jam them into a
>> table based layout (or some similar bad practice) and you are going to
>> be serving that to new browsers as well as old browsers such as mac
>> ie5, ie6/7 and opera 7 __and__ 2) you want the new browsers to act
>> like old ones such as mac ie5, ie6/7 and opera 7. `<!DOCTYPE html
>> PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/
>> DTD/xhtml1-strict.dtd">` is an option although `<!DOCTYPE html>` would
>> trigger equivalent behavior in browsers. i know this is a mostly
>> pedantic since radiant doesn't even use the non-standard table cell
>> handling feature almost standards mode triggers but does this bother
>> anyone else? (and not even using the one feature you get by invoking
>> this "bastard" rendering mode makes it an even more questionable
>> decision to me)
>
> Can you refer me to an article on this or provide a fuller
> explanation? I'm not sure that I understand what we are doing wrong
> and why it upsets you.
it's not really upsetting; more of a pet peeve.
http://hsivonen.iki.fi/doctype/ is the most lucid explanation i've
come across. the relavent bit:
"Firefox, Safari, Chrome, Opera (since 7.5) and IE8 also have a mode
known as “the Almost Standards mode”, which implements the vertical
sizing of table cells traditionally and not rigorously according to
the CSS2 specification. Mac IE 5, Windows IE 6 and 7, Opera prior to
7.5 and Konqueror do not need an Almost Standards mode, because they
don’t implement the vertical sizing of table cells rigorously
according to the CSS2 specification in their respective Standards
modes anyway. In fact, their Standards modes are closer to Mozilla’s
Almost Standards mode than to Mozilla’s Standards mode."
it's not that it causes any "harm" (the browser should still use the
rest of it's normal standards mode) just that triggering that mode is
useless (radiant's table don't use this "feature"). as i said it's a
pedantic issue. i think i can still find happiness if the funky
doctype stays :)
>> the good:
>>
>> * gone is the flash message that makes the ui jump around. i have a
>> feeling it may be coming back at some point so i beg you to reconsider
>> the jumping behavior; it's the worst part of the current ui. make it
>> stick to top or bottom (or middle) of the screen; anything but
>> suddenly and drastically affecting the layout. even a javascript alert
>> would be better than feeling nervous about having the thing you were
>> about to click jump out from under your click.
>
> It's not completely gone, but it is in most circumstances. The main
> place that it is still used is when there are errors on the form. I
> don't like it when they disappear though. Sean can we change this back
> to the old behavior?
it's the "page saved" ones that are gone that were the issue. i like
the flash for validation errors. if the "page saved" one has to come
back then i'm with you on hoping it can go back to the non-fading
behavior. personally i throw in a little css to make it fixed to the
bottom of the screen and remove the word "below" so that the add child
button for the homepage is always in the same location. since ie6
support is out position:fixed might be an option.
>> * the change password ui is a nice touch. i've had a couple of clients
>> ask why they have to change their password when they update their
>> email address (which i always ask them to do once the site launches).
>
> I'm hoping to add a reset your password feature at some point in the
> near future too.
awesome.
>> * i prefer the content/design vs. pages/snippets/layouts although i'd
>> put snippets in design and only pages in content. i can see why
>> developers consider snippets as content but to me it still feels more
>> like the content you'd find in a layout except that you might not want
>> the snippet content on every page. i remove all tabs (even the pages
>> tab) from the interface for clients then build the site in such a way
>> that they never need consider anything outside the content of the page
>> they want to edit. i've hacked extra buttons on to the textile_editor
>> a couple of times to provide one click access to insert 1 or 2
>> snippets that they might need but i never said the word "snippet" to
>> anyone and those were exceptions to the rule. maybe it's that approach
>> that tends to lump snippets and layouts together and i could be alone
>> there.
>
> Yeah this is a hard one. We've considered putting snippets in both
> places. Does anyone else feel strongly about this?
i haven't had a look at the technical details of the new tabs
interface but i'd guess having it in both would make it easier to
remove from one; i.e. you wouldn't have to do anything real tricky
like moving it from under content to design. so if it's between having
it in content only or content and design i'd vote for both.
>> * the url on the view site button makes me think it's going to be a
>> popup. i hope that's the case but why the #view_site_popup url instead
>> of just target=_blank is it going to open an iframe in the admin ui or
>> something? i'd prefer target=_blank to an iframe since an iframe would
>> have essentially the same problem you already have where "view site"
>> is more accurately "switch to site view" or something where switch is
>> the important part. i want "view site" to mean "open a new window (or
>> tab) with the site view" where new is the important part. as a bonus
>> with target=_blank it's up to me and my browser whether that means
>> open a new window/tab on top of or behind the current one both are
>> useful.
>
> The URL was incorrect. This has been corrected in the application. I'm
> not sure about the target=_blank suggestion. Part of me feels that it
> should be left up to the user. After all, the user can Control/Command
> +click a link to get it to open in another window/tab.
that's a fair concern and i'm willing to continue installing a trivial
"extension" to get my preferred behavior; mostly because my clients
seem to prefer the new window and not realize/remember they can use
command/control click.
John W. Long
> no i just meant that the 3rd heading isn't really necessary. the
> Content > Pages headings already tell you everything; "Pages" just
> takes up space.
> http://skitch.com/johnmuhl/b9ub7/radiant-cms-publishing-for-small-
> teams
I see. The small "pages" heading is really a heading for the table
cells. On the same row there is also the "Status" and "Modify"
headers. I think that this information while unnecessary for
experienced users is helpful for people who are not familiar with the
interface. I'm trying to balance minimalism with helpfulness.
>> I'm not sure that I understand what you are referring to here. Can
>> you
>> post a screenshot of what you mean and explain why it is
>> inconsistent?
>
> http://skitch.com/johnmuhl/b9ung/radiant-cms-publishing-for-small-
> teams
Again this isn't inconsistent. It's just another type of heading (a
table heading).
> i'd be fine with just having the core js concatenated and letting
> extensions add additional requests. i hardly ever have 10 extensions
> loaded on a production site so it'd still be a net gain.
I agree. Please work on this.
> it's not really upsetting; more of a pet peeve.
> http://hsivonen.iki.fi/doctype/ is the most lucid explanation i've
> come across.
Which doctype are you suggesting that we use? I think I prefer 1.1.
john muhl
>> it's not really upsetting; more of a pet peeve.
>> http://hsivonen.iki.fi/doctype/ is the most lucid explanation i've
>> come across.
>
> Which doctype are you suggesting that we use? I think I prefer 1.1.
<!doctype html> is the only one that makes any sense to me when i'm
authoring new pages. if you're really into the big w3c doctypes then i
guess any one of the following would do:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd"> # most preferable w3c doctype
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
john muhl
http://github.com/rails/rails/blob/01d92021e69f54def1ec8103b2b99f907dd88ec4/railties/html/index.html
and am more convinced <!doctype html> is the right choice.
john muhl
> On Wed, Sep 16, 2009 at 8:53 PM, John W. Long <johnwl...@gmail.com> wrote:
>> On Sep 15, 5:43 pm, john <johnm...@gmail.com> wrote:
>>>
>>
>> ...I would definitely consider a pull request.
here's a first try:
http://github.com/johnmuhl/radiant/commit/5a3a66690b14ab1a97094a9388a63e2525870ba3
the page titles are "Home Page - Radiant CMS - Publishing...", "Normal
Layout - Radiant CMS - Publishing...", "header Snippet - Radiant CMS -
Publishing..." etc.
>>> * still 11 network request just for the javascript...
http://github.com/johnmuhl/radiant/commit/1df3630be2597cd13c8d47e644465f000417eaf5
on full page reloads i see an average of about 70ms being spent
getting javascript whereas before it was around 120ms (local server in
production).
>>> * i still don't agree with the choice of doctype...
http://github.com/johnmuhl/radiant/commit/32d0ba450f77d8e65d5090ede194789b382e6385
nothing exploded and a quick pass with machine validation only
complained about @summary on table and @caption being marked
non-conforming; @caption was always non-conforming and @summary is
still being debated in html5 so i don't see any need to change until
it's settled. @caption should just be replaced using the conforming
@data-* attributes so you'd have @data-caption="..." and use that in
script instead of @caption. as i mentioned in another message
<!doctype html> will be the default doctype for rails 3 so it seems
like the way to go. if it's accepted i'd be willing to go through and
check what a machine can't for conformance.
unrelated to doctypes i found another conformance error where <div>
was nested in <p> in required field errors which is fixed in:
http://github.com/johnmuhl/radiant/commit/41a0c0b441a7b608bf2d41d983909115e0d6179e
John W. Long
@snippet.name, etc. be escaped? Also I wonder about tests for some of
this.
Just gave you commit rights on GitHub. Please commit what you have.
One other thing, do you have time to update the prototype with your
title changes? We try and keep the two in sync even though it requires
some extra effort.
http://recursivecreative.com
john muhl
>
> These all look good. One question on the title change, shouldn't
> @snippet.name, etc. be escaped? Also I wonder about tests for some of
> this.
it may need escaping. i'll take a look as time permits this week.
although it may end up having to be next week.
> Just gave you commit rights on GitHub. Please commit what you have.
thanks. will do.
just to be sure are you asking that all the changes (i.e. title,
javascript concatenation, html5 doctype and <div> in <p>) or just the
title changes be committed?
> One other thing, do you have time to update the prototype with your
> title changes? We try and keep the two in sync even though it requires
> some extra effort.
sure.
John W. Long
> just to be sure are you asking that all the changes (i.e. title,
> javascript concatenation, html5 doctype and <div> in <p>) or just the
> title changes be committed?
Yes. Thanks for asking.