Blueprint CSS location
Christian Mohn (h0bbel)
system/admin/css which got me thinking a bit (uh-oh).
Is that the best location for it? isolating it inside admin/ means a
couple of things:
*) Habari admin specific customizations of the Blueprint CSS Framework
will be isolated to the admin section.
*) The shipped Blueprint CSS Framework will only work for the admin
section, and any themes developed using it needs to provide their own
copy of Blueprint.
Habari already bundles jQuery, and thats generally available for theme
designers to use, why should this be different for Blueprint? If the
admin section needs specific edits of the Blueprint files, that could
be done by using overrides in admin.css (It would require that the
load order of the css files change a bit, but I would think thats a
minor issue).
Basically my idea here is to be able to say: "Habari comes prepackaged
with the hotness of jQuery, and the cleanliness of Blueprint CSS ready
for theme developers" :-)
Comments?
Scott Merrill
> Basically my idea here is to be able to say: "Habari comes prepackaged
> with the hotness of jQuery, and the cleanliness of Blueprint CSS ready
> for theme developers" :-)
>
> Comments?
+1
--
GPG 9CFA4B35 | ski...@skippy.net | http://skippy.net/
Thomas Kalve Pedersen
> Basically my idea here is to be able to say: "Habari comes prepackaged
> with the hotness of jQuery, and the cleanliness of Blueprint CSS ready
> for theme developers" :-)
+1 from me to
--
Thomas
tinyau....@gmail.com
>
> Basically my idea here is to be able to say: "Habari comes prepackaged
> with the hotness of jQuery, and the cleanliness of Blueprint CSS ready
> for theme developers" :-)
>
> Comments?
>
+1 from me.
--
tinyau
Root
Christian Mohn
It's MIT licensed, no problem there. The only thing, licensing wise, that
needs to be done is highlighted in
http://code.google.com/p/habari/issues/detail?id=384
Christian
Chris J. Davis
Owen Winkler
Ok, so.... Where do we put this stuff?
Owen
Chris J. Davis
Christian Mohn
considered the same?
/external
/3rdparty/
?
Christian
-----Original Message-----
From: habar...@googlegroups.com [mailto:habar...@googlegroups.com] On
Behalf Of Chris J. Davis
Sent: 29. august 2007 20:19
To: habar...@googlegroups.com
Subject: [habari-dev] Re: Blueprint CSS location
Michael Bishop
me. Things like Simple Pie could also go there one could assume, if
it were decided to be bundled with core.
~miklb
Christian Mohn (h0bbel)
party" libraries would make sense. At least to me it does.
Christian
Rich Bowen
/contrib - to indentify it as contributed code? Guess JQuery could beconsidered the same?
/external/3rdparty/
Root
Christian Mohn (h0bbel)
Christian
Root
-2 for bundling it
-3 for saying *its for theme developers*
I asked about this previously. The answer I was given was that anyone
writing up the admin could use any tool they like.
Fair enough. But this is way beyond that. Way beyond.
My objection to this is that it is generally immaterial what I
or the rest of us do / do not do with it.
We do not have to use it.
But a lot of folk will follow what we do.
They will use it as a base.
They will assume that Blueprint is somehow best of breed.
It is not.
Some of it is just convenient but is unnecessarily prolix.
Some of it is highly controversial.
eg: the typography schemata.
So: if we start saying: well we can edit it
Then why use the darn thing in the first place?
It is a rattlesnake.
If it gets out we will never recapture it :)
If we can't write our own CSS we shouldn't be in this business.
And nor should themers.
Just my 2 cents.
Some of
On Aug 31, 8:04 am, "Christian Mohn (h0bbel)" <h0b...@gmail.com>
wrote:
Root
On Aug 31, 8:23 am, Root <atthe...@gmail.com> wrote:
> -1 for using blueprint. css at all
> -2 for bundling it
> -3 for saying *its for theme developers*
>
What is admin? Really?
It is a gigantic form.
And a lot of tables.
The table funkiness has come to light already.
There are some horrors lurking in the blueprint.
It is an ideal get you started tool for designers.
A bit better than using Front Page.
But it is not a proper thing for interface coders.
Christian Mohn (h0bbel)
that I probably should have used FrontPage instead.
Man, there is so much attitude/feelings/whatever in these discussions
that I don't think anything good will come of it at all. Sorry, but I
just tried running with the ball after blueprint was introduced.
Christian
Root
committed to trunk without any prior discussion.
And in sofar as I raised it previously I was misled by the answer.
I am entitled to say that.
Blueprint in my opinion is wrong for Habari.
I do mind explaining why.
But I do not mean to sound as if I have an *attitude*.
I don't.
Maybe its just the way I write. My bad.
But if any one had asked prior to the committing I and a couple
of other folk could have been better prepared to argue on the merits.
This is a fait accompli. OK.
But it is very very harmful.
Please do not say you were not warned.
On Aug 31, 12:18 pm, "Christian Mohn (h0bbel)" <h0b...@gmail.com>
wrote:
Christian Mohn (h0bbel)
"admin/dashboard" discussion seems to be going haywire. The language
used certainly doesn't help.
I don't have an opinion on blueprint vs whatever, I've used blueprint
a bit and I like it. Thats all. I have never entered a discussion
regarding the html and/or css or anything, simply because it's not my
field of expertise. I dabble in it, thats it.
Please, everyone, get your acts together and try to unite on something
instead of bashing each other on a mailinglist. If someone has
specific ideas on what should be done, come forward with them in a non-
attacking manner. Try to work as a community, not as single entities
with your own personal agendas.
</soapbox>
Scott Merrill
> Well I am sorry that you feel like that. But Blueprint has been
> committed to trunk without any prior discussion.
Yes, it has. And it can easily be backed out. We had the whole of
Smarty in our repository in the early days: it landed there without much
discussion. After discussion, it was removed.
The fact that something is in the repository is not indicative that it
will stay there.
The fact that something landed in the repository without discussion is a
good item for discussion: should that have happened? Maybe not. If
that's your opinion, why not put forward a positive spin, rather than a
negative one?
"In the future, can folks please open a ticket or start a mailing list
discussion before adding third-party libraries to the repository?"
> Blueprint in my opinion is wrong for Habari.
> I do mind explaining why.
Pity. I'd like to learn more. Even though CSS and design are far
outside my skillset, I still like to be able to speak intelligently
about the whole of Habari.
When we talk to folks at the upcoming Ohio LinuxFest, I'd like to be
able to share with them why we are or are not keeping Blueprint.
"Because khaled likes it" and "Because root doesn't like it" are both
unacceptable explanations.
We coders explain ourselves to one another, and to the larger community.
We explain why we do and do not use certain functions, or why we tackle
a certain problem in a certain way. I hope that the design community
within Habari can be as courteous to us as we try to be to them.
So: what's bad about Blueprint? What _specifically_ is wrong with
including it in Habari? What alternatives can you propose in place of
Blueprint?
> But if any one had asked prior to the committing I and a couple
> of other folk could have been better prepared to argue on the merits.
We're not always going to ask permission before we do things. I think
it's perfectly okay for a passionate contributor to occasionally get
fired up and DO something without presenting it to the group first. We
can talk about it civilly and constructively after the fact. I don't
want this to be the normal modus operandi, but I also don't want our
design-by-committee to develop bland, soulless software. :)
There have been several prior examples of this. We've gotten through it
because we all have the same goal in mind: to make Habari as great as it
can be.
> This is a fait accompli. OK.
> But it is very very harmful.
> Please do not say you were not warned.
Who wasn't warned about what?
Rich Bowen
-1 on this. no doubt in my mind at all.
Rich Bowen
-1 for using blueprint. css at all-2 for bundling it-3 for saying *its for theme developers*
Owen Winkler
>
> Please, everyone, get your acts together and try to unite on something
> instead of bashing each other on a mailinglist. If someone has
> specific ideas on what should be done, come forward with them in a non-
> attacking manner. Try to work as a community, not as single entities
> with your own personal agendas.
I agree -- I'm not really fond of the bickering. I think if we're
going to move beyond arguing then we need to hear specific objections
to what is being proposed. To that end, I will offer why I think
Blueprint was chosen for use for our admin.
Blueprint, although obviously not complete, seems like an excellent
start to a useful generic CSS framework. It immediately offers a good
deal of layout control without having to hand-code everything. By
coupling something like Blueprint to control layout positioning and
grouping with a some code on the back-end, we can provide a very
flexible admin layout with the potential for modification via plugin.
While it may be possible to use custom CSS to control the admin - as
Root pointed out, if we can't write our own CSS, then we have no
business here - custom CSS does not provide us the flexibility to
rearrange content elements dynamically without altering the CSS
definition itself. If such an alternative solution exists, nobody has
suggested it.
Blueprint is also another open-source project, which means we don't
have to maintain it ourselves. We can contribute any beneficial
changes back to the Blueprint project, but can also trust that others
working on the project who have concerns about how it operates will be
working on improving it as well. We can benefit from these
improvements without focusing all of our efforts on them.
There are obviously problems with the library. It is not perfect. I
think it can be improved to the point where it would be acceptable for
use, and I think there are enough people in the Blueprint project and
here that this can be done before our 1.0 release. You may disagree.
That is fine. But if you can't put forth the effort to even explain
why, then complaining serves no purpose whatsoever.
If people would focus on fixing what problems it has instead of
complaining that it does have problems, things would be accomplished.
If there is an alternative that accomplishes the goals I've outlined,
we are not married to Blueprint. I would prefer a superior Habari to
saying that we use Blueprint.
We do not need to have discussion about every item prior to committing
it to the repository. Sometimes, the only way to see how a thing
works is to have it worked out in code. This doesn't mean that we
can't back something out if it really isn't working or isn't
appropriate. But to do that, we need some coherent argument against
it that can convince others of the case. So far, Blueprint looks to
be working reasonably well. I suppose that the major issue is
something underlying how it works, but I'm not sure what that is.
I am very interested in hearing why Blueprint is not right for Habari.
I understand that if it is wrong, there are implications that we'd be
encouraging community use of something that may not be appropriate,
which I certainly wouldn't want to do. But I don't understand what's
wrong with it. Please help.
Owen
Owen Winkler
>
> Sorry that I stepped into an existing conversation that I apparently didn't
> fully grok. In general, I feel oogy about putting someone else's open source
> project, wholesale, into our svn tree. It feels like bad practice on several
> levels, which I could elaborate further if needed. This is what 'svn
> externals' was invented for.
This is actually a very good suggestion. Maybe we should consider
this at least in the short term.
Owen
Rich Bowen
Well I am sorry that you feel like that. But Blueprint has beencommitted to trunk without any prior discussion.And in sofar as I raised it previously I was misled by the answer.I am entitled to say that.Blueprint in my opinion is wrong for Habari.I do mind explaining why.But I do not mean to sound as if I have an *attitude*.I don't.Maybe its just the way I write. My bad.But if any one had asked prior to the committing I and a coupleof other folk could have been better prepared to argue on the merits.This is a fait accompli. OK.But it is very very harmful.Please do not say you were not warned.
Root
Typo.
Scott Merrill
> I meant to say I do NOT mind explaining it.
Please explain your position so that we may all benefit from your
expertise and opinion on this issue.
Thanks,
Scott
Root
problem which does not exist.
We can't delegate writing our own CSS to a whole bunch of third party
strangers no matter who they are or what they do.
Blueprint has its uses, ie large (very large) sites. Our admin is only
one page albeit intensely dynamic.
And its target audience is folk who can not do it themselves or do not
need a custom jpob.
That does not include us. We are building an application not a web
site anyway.
Some of the very bits we need the most are not in the blueprint in any
detail anyway.
At least not in a form I am comfortable with.
Forms and all things therein are the toughest item in CSS from the
cross platform pov.
There is some good stuff in Blueprint.
But adopt it wholesale. No.
And the typography section is exceptionally poor.
And it is so poor it knocks my confidence in the rest of it.
It is new.
Untested.
In development.
I can not see a single reason to contemplate it.
But I can see why some folk find it superficially appealing.
I understand that.
Scott Merrill
> Well it seems to me that this is an off the shelf solution for a
> problem which does not exist.
What problem?
> Some of the very bits we need the most are not in the blueprint in any
> detail anyway.
What bits do we need that it lacks? Would it be possible to contribute
those bits upstream so that we -- and all other Blueprint adopters --
can benefit?
> At least not in a form I am comfortable with.
What about the bits that are present make you uncomfortable? In what
specific ways are they insufficient? If it's purely a matter of
opinion, please explain your opinion as clearly as possible, so that we
can separate technical deficiency from personal dislike.
> There is some good stuff in Blueprint.
What about it is good? Is there a quantifiable amount of "good" versus
"bad"? Which has more?
> But adopt it wholesale. No.
Why not? What technical objections do you have for the inclusion of
Blueprint -- or any other CSS solution?
> And the typography section is exceptionally poor.
In what way is it poor? What superior alternatives do you suggest?
> And it is so poor it knocks my confidence in the rest of it.
> It is new.
> Untested.
> In development.
Habari is all of those things, too.
> I can not see a single reason to contemplate it.
There is no single reason to contemplate Habari, yet here we are... :)
Root
It is a professional difference of opinion.
I need time to get more together on this.
But a bit of CSS shouldnt be like pulling teeth. :)
Owen Winkler
>
> We can't delegate writing our own CSS to a whole bunch of third party
> strangers no matter who they are or what they do.
We are not. Blueprint is a library, just like any of a number of PHP
libraries we might use for the Habari internals. We still need to
supply our own stylesheets to accomplish specific tasks. Blueprint
simply makes initial positioning and layout easier.
> Blueprint has its uses, ie large (very large) sites. Our admin is only
> one page albeit intensely dynamic.
Our admin is multiple pages. Our admin is also intended to be more
dynamic than it currently appears. The CSS provided by Blueprint
could also be used by people designing their own web sites, which
could be large, although I don't see validity in the claim that
Blueprint is only for very large sites. It's ok for very large sites
but not for small ones? I don't follow that logic.
> And its target audience is folk who can not do it themselves or do not
> need a custom jpob.
> That does not include us. We are building an application not a web
> site anyway.
You misunderstand the audience of Blueprint. It's for people who
don't care to waste their time fiddling with little details just to
get a flexible layout up and running quickly. A custom job may be
better at simple positioning/layout than employing Blueprint alone,
but it will likely not be as flexible as we require. I see no need to
follow a "not invented here" path for a tool that seems to be doing
the job to our needs.
> Some of the very bits we need the most are not in the blueprint in any
> detail anyway.
> At least not in a form I am comfortable with.
> Forms and all things therein are the toughest item in CSS from the
> cross platform pov.
What Blueprint does not provide or does not do that we would want done
is something we'll need to include separately. We obviously can't use
Blueprint for forms, and we will have to build that separately. I
think that this is not a blocker for using Blueprint, since you could
say this about any stylesheet that only provides layout.
> There is some good stuff in Blueprint.
> But adopt it wholesale. No.
> And the typography section is exceptionally poor.
> And it is so poor it knocks my confidence in the rest of it.
I agree that the typography is poor. It can be improved. You are in
a unique position to sculpt the formation of this typography. Offer
fixes that we can send to Blueprint to make both it and Habari better.
> It is new.
> Untested.
> In development.
As is Habari.
After we've outlined its clear advantages to our goals with the
expectation that the rough spots can be improved, saying solely that
you're not comfortable with it is simply not enough to sway me against
it.
An effective message would begin "Here are the emotionally detached
reasons why Habari should not use Blueprint, including clear examples
of the problem areas." Less than this is not really useful. An
example of how we could do it without Blueprint, while interesting, is
also not useful because, as I understand your proposal, it does not
address the flexibility required by the admin. Perhaps I wasn't clear
in this thread on this point, but you can read about it here:
http://groups.google.com/group/habari-dev/browse_thread/thread/2b53c5000ebbb3e4/
I really want to understand this thing that could be a problem for
Habari, but this is the last message I'll send to try to elicit your
reasoning for your dislike of it. It's not an effective use of time
to coerce you to articulate what should initially be made obvious.
Owen
Kristin Pishdadi
Owen Winkler
>
> I PITTY THE FOOL.
Your Mr.T defense has weakened my resolve. I'm convinced. From now
on, everything is to be output for Lynx as the target browser.
Owen
Scott Merrill
> When I say I do not like something that is not a personal dislike.
> It is a professional difference of opinion.
The more specific you can be in your emails, the smoother the
discussions will go. If you can present specific items of concern,
others can evaluate those items and respond in turn.
What are your specific professional differences? Based on your
professional experience, in what specific, measurable ways is Blueprint
deficient? What alternatives do you suggest in order to solve the
issues for which Blueprint is being considered?
> I need time to get more together on this.
> But a bit of CSS shouldnt be like pulling teeth. :)
I'm not entirely sure what that sentence means: are you commenting on
the discussion process in which we are currently engaged, or are you
commenting on the use of the Blueprint framework instead of writing our
own CSS?
If you're railing against the iterative discussion process in which pros
and cons are discussed factually and dispassionately, there's little
else we have to discuss. The meritocracy model we pursue applies to all
contributions, not just PHP code. If you are unable or unwilling to
engage in a meaningful discussion to work toward consensus, then Habari
may not be a good project for you.
If you're railing against the use of Blueprint for Habari, then I will
wait patiently for your explanation of its technical deficiencies, and I
will carefully evaluate as best I can your proposals for solutions to
the problems for which Blueprint is being considered.
Cheers,
Scott
Root
Really I am not.
Michael Bishop
My question is this. What constitutes a commit? 10% of the code for a
change that effects a major portion of the project, or a full complete
commit of a proposed solution? This was my original point of
contention. I have no issues with CSS frameworks, I've toyed with the
YUI CSS framework, and think the Blueprint could be a nice starting
point for projects. There's no rule that the whole thing be used, be
it their button CSS, their typography CSS, etc. I have no issues with
major changes being introduced, regardless of their area. Point in
case, the whole deleted post status. Personally, I don't like seeing
my deleted posts on the site, however, there has been numerous thought
out, logical discussions about it, and it continues to go on in that
manner. At the same time, the change was made in it's entirety, not
small, random increments.
Please note, these questions are asked as much as a champion and user
of Habari, and concerned with it's direction, as they are about
someone who wants a better understanding of open source development,
and the meritocracy model.
~miklb
Rich Bowen
Nothing is a fait accompli until we release code. We are in CTR -Commit Then Review. People (and I'm not at all talking about just you- I've observed this from a significant number of people) need tostop reacting like every commit is a major decision that was arrivedat without their input. Seriously, it's a really harmful attitude,because it makes people afraid to commit experimental code for fearof offending someone.CTR - Commit Then Review - means that folks are at liberty to commitstuff, and everyone else is at liberty to discuss the commit afterthe fact.My question is this. What constitutes a commit? 10% of the code for achange that effects a major portion of the project, or a full completecommit of a proposed solution? This was my original point ofcontention. I have no issues with CSS frameworks, I've toyed with theYUI CSS framework, and think the Blueprint could be a nice startingpoint for projects. There's no rule that the whole thing be used, beit their button CSS, their typography CSS, etc. I have no issues withmajor changes being introduced, regardless of their area. Point incase, the whole deleted post status. Personally, I don't like seeingmy deleted posts on the site, however, there has been numerous thoughtout, logical discussions about it, and it continues to go on in thatmanner. At the same time, the change was made in it's entirety, notsmall, random increments.
Michael Bishop
SVN in the last couple of days.
http://code.google.com/p/blueprintcss/source
Scott Merrill
> Not exactly familiar with svn externals
http://svnbook.red-bean.com/en/1.0/ch07s03.html
It's a way to include some other project's SVN code in your project.
So, if we end up relying on Blueprint, there's no reason for us to keep
and manage our own local copy of their source tree inside of our source
tree. Instead we say "Hey, Subversion, include that stuff over there in
this local directory here."
In this way, we can have an always-up-to-date copy of their stuff in our
checkouts.
Michael Bishop
was what they were getting at. Interesting in their example, they do
indeed use /third-party as a directory name.
Christian Mohn
something it cascades down to Habari too. Also, if we are modifying it to
our needs, we can't rely on externals unless we override it somewhere.
I'm not opposed to including it, I'm just pointing it out.
Christian
Rich Bowen
One potential problem there, is that if we do that and blueprint breaksomething it cascades down to Habari too. Also, if we are modifying it toour needs, we can't rely on externals unless we override it somewhere.I'm not opposed to including it, I'm just pointing it out.
-----Original Message-----Behalf Of Michael BishopSent: 31. august 2007 21:13To: habari-devSubject: [habari-dev] Re: Blueprint CSS locationThanks for the explanation. I did read that page, and thought thatwas what they were getting at. Interesting in their example, they doindeed use /third-party as a directory name.On Aug 31, 3:09 pm, Scott Merrill <ski...@skippy.net> wrote:Michael Bishop wrote:Not exactly familiar with svn externalsIt's a way to include some other project's SVN code in your project.So, if we end up relying on Blueprint, there's no reason for us to keepand manage our own local copy of their source tree inside of our sourcetree. Instead we say "Hey, Subversion, include that stuff over there inthis local directory here."In this way, we can have an always-up-to-date copy of their stuff in ourcheckouts.--GPG 9CFA4B35 | ski...@skippy.net |http://skippy.net/
khaled Abou Alfa
Why Blueprint? I played around with it and was genuinely surprised by the speed at which I came to grips with it and how it works. It made the process of placing things in the exact place that I wanted a trivial process.
Oh sure it's lacking in lots of areas (like the aforementioned forms etc) but that's not what I was intending it's use for. I don't ever expect BP to be the css of Habari and that's it. What the 3 files do is enable us to create and position things clearly in this early developing stage, where things are constantly changing. Areas are being added, features are changing shape and the requirements are evolving. BP allows us to be flexible in that manner. Changing the grid sizes is as simple as tweaking where the classes are called in every div. The beauty of this approach for me is that it will look the part from this very early stage of development.
Do I think BP is here to stay? No. In all honestly a LOT of BP isn't really for us. However the important thing is to take things that BP has done well and use it as best we can in our application. The code is there for everyone to modify and remove and tweak and add. I've been tweaking the files slightly and I honestly thought that people would see this benefit as well.
For those that believe that I did this because I wanted and didn't consult anyone, that's not the case. I did consult the other developers. Some were interested, while others were apprehensive. It's the exact same scenario that came about when I proposed tiddlywiki for our manual. Maybe naively I thought that because we're using SVN that would could turn the clock if it was felt that I'd fucked things up bad. As Scott said, it can be removed if it's really becoming obtrusive. My impression is that I can see a great deal of promise in what it's provided to the aesthetics of the admin, something which I have been meaning to help sort out for a good long time. Maybe I should have consulted everyone on the mailing list first. To be honest I didn't think it would create such a massive backlash for it's inclusion. Once again naive on my part.
To try and further illustrate the point about flexibility of BP, the attached jpg shows what the mockups looked like that I started looking at on Sunday. It's pretty darn close to what we have right now, but you'll notice that things have been tweaked accordingly, which is to be expected when new areas are put forward (like the recent activity log). With BP I was able to accommodate this without much concern.
Don't like the typography? I hear you there, but we can sort it out, it's not that complicated a stylesheet. We are definitely not beholden to BP. Like I said, lets take the good stuff and discard the stuff we're not happy with. Or hell some might think that it would be even better to put back to the BP project which is in and of itself another open source project.
Rich Bowen
Michael Bishop wrote:Not exactly familiar with svn externalsIt's a way to include some other project's SVN code in your project.So, if we end up relying on Blueprint, there's no reason for us to keepand manage our own local copy of their source tree inside of our sourcetree. Instead we say "Hey, Subversion, include that stuff over there inthis local directory here."In this way, we can have an always-up-to-date copy of their stuff in ourcheckouts.
Root
limitations of Blueprint I am a bit more comfortable with this.
My issue - if I had one - was not that I am anti Blueprint entirely.
But I am in favour of hand written custom made CSS built from the
ground up by us and for us.
I can't see why anyone could not want that. If I open the bonnet of a
Rolls Royce I do not expect to see a Chrysler
engine.:)
This could be a highly technical - and tedious discussion for people
not familiar with the nitty gritty but here is one example. In order
to clear the floats Blueprint uses a clearfix class which employs a
pseudo class of :after. That is from the CSS 2.1 recommendation. If
we use it we are commited in our most critical area - a stable layout
- to being unable to support non CSS 2.1 browsers. There may be a case
for that but I am not buying it myself. But where are wrong in my view
is to head off down this path without a clear determination of what
our expectations are vis a vis legacy platforms and a better
understanding of what the consequences of those choices are.
I could go through it here line by line but what is the point?
In my view not only is the typography suspect because it gives very
poor cross platform performance including IE 7 but it leads to
instability in both the width and height dimensions because the
Blueprint does not follow the best of breed conventions in this regard
either.
This may be a frustrating process for real programmers who basically
speaking just need to get things running.
Unfortunately CSS implementation is so erratic that interface design
is a snake pit of choice and compromise.
It is rarely perfect. It is not easy. Some folks do more of it than
others.
Finally if we need stuff ourselves that is obviously going to be
project specific.
Blueprint is generic. Our lives are complicated enough without getting
into other open source projects
which have completely different objectives. I would not want to get
into code exchange.
And the idea of svn to the Blueprint code horrifies me.
I have always wished - fervently - that I was a better writer. I
rarely mean to offend anybody.
But if I do - then I apologise.
On Aug 31, 6:22 pm, "Owen Winkler" <epit...@gmail.com> wrote:
> http://groups.google.com/group/habari-dev/browse_thread/thread/2b53c5...
Chris J. Davis
<002-admin-introduction.jpg>
Root
My feeling on code exchange is partly personal.
If I wanted to help out over there I could always go and throw
in my 2 cents. The whole project is not my thing.
But that is not it. My concern is that if we get into editing we will
be editing for Habari.
I do not want any generic code sharing issues to cloud that.
Another example: Typography. The whole thing runs on fixed (px) based
font sizing.
Well nobody does that do they? We all a global reset at 76% followed
by ems for fonts and heights and percentages
for width.
More on the .clearfix class. When I say non CSS 2.1 browsers that
includes browsers which purport to follow it but do not. IE 6 for
example does not support pseudo classes. Kinda inconvenient - whoops
there goes what 60% of our users maybe? WE would be right into Kubrick
territory.
And on khaled and his IE max width thing. Yes and no. If some one
could just state clearly if javascript is / is not going to be used in
admin we can get into things like that.
We have an expression here which I hope you will forgive. We are
designing a pig in a poke.
And generally when people admire passion it means they think the guy
is a PITA. Probably right. :)
Scott Merrill
> And on khaled and his IE max width thing. Yes and no. If some one
> could just state clearly if javascript is / is not going to be used in
> admin we can get into things like that.
No one is going to say "we require javascript for the admin" until such
time as we've had reasonable time to discuss the relative strengths and
weaknesses of such a requirement. After that conversation, there will
hopefully be some consensus, and then you'll have your answer.
Speaking solely for myself, I'm comfortable requiring javascript for the
core administrative interface. All of the machines from which I will
execute administrative tasks on my blogs have javascript-enabled
browsers. I am a sighted, non-disabled person, so I don't have any
constraints on the "normal" interaction with my blog. I don't know
anyone who is blind, or disabled, so I don't know how those limitations
bear on design decisions for the admin interface.
I would like to see a mobile admin interface constructed, that does not
use JS, so that I can -- should I so desire -- administer my blog from
my cell phone.
> And generally when people admire passion it means they think the guy
> is a PITA. Probably right. :)
What a crock. It's comments like this that detract from any useful
dialog about features and functionality.
Root
until the specification for Javascript
and the browsers is buttoned down. Those things determine how it needs
to be coded. This is ass backwards.
But never mind.
Andrew da Silva
Root, since day one you haven't made a constructive comment on this
group, as far as I can recall. Every time I read one of your replies
it criticizes someone's work or contribution without offering
solutions. But, truth be told, most of those times, you were right. I
just don't like to see someone bitching while not bringing forward
suggestions on how to resolve a problem. But like I said, most times
you are right, which brings me to the next point.
The Blueprint framework, in my opinion, is a great idea, but should it
be part of the admin core? I don't think so. Would it be helpful for
the default admin design? I don't think so, but should we allow users
to use such frameworks to build their own admin design? Absolutely.
Therefore, I think the admin area should work just like the content
works, use themes and handlers.
We need to lay down the features we want and how to implement those
ideas. For example, FormUI, what should it do, to what extend should
it be flexible, how should we do it, etc. I think the Roadmaps threads
are a great way to do so, or by creating issues. Also, what is going
on with the milestones idea?
+1 on CTR.
Chris J. Davis
On Sep 1, 2007, at 4:44 PM, Root wrote:
>
> Chris I am sorry for your loss.
Thanks.
> My feeling on code exchange is partly personal.
> If I wanted to help out over there I could always go and throw
> in my 2 cents. The whole project is not my thing.
> But that is not it. My concern is that if we get into editing we will
> be editing for Habari.
> I do not want any generic code sharing issues to cloud that.
I would agree. One of the requirements that I would put forth if we
are to use Blueprint is that we MUST send any additions/bug fixes back
to the Blueprint folks.
> Another example: Typography. The whole thing runs on fixed (px) based
> font sizing.
> Well nobody does that do they? We all a global reset at 76% followed
> by ems for fonts and heights and percentages
> for width.
That is a great point. And I agree completely. If we were to use BP,
we would want to create a ticket with them about this and push for
some change to a more accessible approach.
>
>
> More on the .clearfix class. When I say non CSS 2.1 browsers that
> includes browsers which purport to follow it but do not. IE 6 for
> example does not support pseudo classes. Kinda inconvenient - whoops
> there goes what 60% of our users maybe? WE would be right into Kubrick
> territory.
This would be another place where we could submit a patch that would
address this bug, and benefit everyone. I am not going to give up
trying to convince you of the rightness of contributing to other OSS
projects!
>
>
> And on khaled and his IE max width thing. Yes and no. If some one
> could just state clearly if javascript is / is not going to be used in
> admin we can get into things like that.
That is another fish that needs frying. I think it is fair to say
that JS will be used in the admin, whether or not it is required is up
for debate.
>
>
> We have an expression here which I hope you will forgive. We are
> designing a pig in a poke.
I don't think I know what that means, so I can't possibly take
offense :)
>
>
> And generally when people admire passion it means they think the guy
> is a PITA. Probably right. :)
I am one to speak my mind. If I think you are being an asshat, trust
me, I will tell you.. in a private email. :)
Scott Merrill
> Well obviously there is no point in moving forward on admin at all
> until the specification for Javascript
> and the browsers is buttoned down. Those things determine how it needs
> to be coded.
Are you suggesting that no work at all can be put forth toward the admin
interface until we decide whether Javascript is a requirement?
If you were in absolutely charge of the project, what decision would you
make with respect to Javascript as a requirement? Why would you make
that decision? What documentation can you provide to back up your decision?
Given that you're not in absolutely control of the project, what is your
preference? What compromises do you feel are acceptable, if any?
> This is ass backwards.
In what way is this ass backwards? In what way does calling it ass
backwards get us closer to a solution?
Are you opposed to experimentation and incremental revisions? Is it
unacceptable to you for us to move forward with temporary working
solutions, so that other aspects of the whole system can be implemented
and refined? It's been our experience so far that several key
components have undergone refinement -- sometimes subtle, sometimes
major -- as the rest of Habari grows toward completeness.
Is the same not acceptable for the admin interface? Is it unacceptable
to have a decent-but-not-finished admin interface as we work out what we
really want and need in an interface? Your push for finalization
suggests to me that you are uncomfortable with incremental progress.
> But never mind.
In what way does throwing your hands up in the air get us closer to a
resolution? Should we read that message as indication that you're no
longer going to be participating?
Are you going to put forward any positive suggestions? Are you going to
put forward working examples of the kind of CSS you'd like to see? Are
you going to put forward any template files for consideration?
Root
On Sep 2, 1:24 am, Scott Merrill <ski...@skippy.net> wrote:
>
> Are you suggesting that no work at all can be put forth toward the admin
> interface until we decide whether Javascript is a requirement?
>
Pretty much so yes. I am saying that specification needs to precede
coding. I wouldn't actually want to stop anyone in their tracks even
if I could.
But I would advocate bumping the spec rapidly up the must do list. On
JS.
And on legacy browser support.
If you were in absolutely charge of the project, what decision would
you
> make with respect to Javascript as a requirement? Why would you make
> that decision? What documentation can you provide to back up your decision?
>
If I was in charge I would set out on the basis that JS was not going
to be used.
I would wait for any specific proposal to use JS for a specific
function to come forward
and then I would examine it very closely on its merits. I would not
preempt any choice that would be made then.
But in general I am not in favour of ajaxified sliding doodads from
hell.
Given that you're not in absolutely control of the project, what is
your
> preference? What compromises do you feel are acceptable, if any?
>
I start from a perspective of standards. If it runs in a browser it
should follow them.
BUT:
We are designing an application. Certain criteria need to be met to
operate the software eg php 5.
Are there really guys who want to use bleeding edge software like
Habari but who still use Netscape 4?
I doubt it? Should we worry if they do? Prolly not. But I hate JS. The
reason I hate it is that I encounter so
many scripts which are badly written that my system freeezes and or
crashes. And that is FF on linux. Regularly. So speaking personally I
browse with JS off by default. Is that a good compromise for Habari?
Prolly not. I am open minded. What I am advocating is getting it clear
before we start. Perfect world? JS has an on / off switch in options
or something.
> > This is ass backwards.
>
> In what way is this ass backwards? In what way does calling it ass
> backwards get us closer to a solution?
>
Ass backwards is I understand a widely used colloquial expression
which emanates from the US.:)
It quite neatly encapsulates the difficulty of writing a programme
without a technical specification in place.
This has historically been a weakness on other platforms. I hope we do
better. Lit majors versed in Shakespeare,
prolly still call it putting the cart before the horse or some such :)
> Are you opposed to experimentation and incremental revisions? Is it
> unacceptable to you for us to move forward with temporary working
> solutions, so that other aspects of the whole system can be implemented
> and refined?
No I am not. In the *artists want to submit complete works* paradigm I
go with the coders.
But every time anyone contemplates coding in admin
(a) they have no spec
(b) they always need to wait for the next mockup or something
I am itching to get started. I am not going to until the spec is
buttoned down.
And nor am I going to start if we go with Blueprint.css. Some folk
here
might think that would be a good thing. :)
It's been our experience so far that several key
> components have undergone refinement -- sometimes subtle, sometimes
> major -- as the rest of Habari grows toward completeness.
>
Subtle / or even substantive change is good. If it breaks go another
way. Yes.
But the admin is unlike the rest of Habari - it is not innovative.
The questions that arise on form building and cross platform issues
are already widely understood. As are the best practices.
> Is the same not acceptable for the admin interface? Is it unacceptable
> to have a decent-but-not-finished admin interface as we work out what we
> really want and need in an interface? Your push for finalization
> suggests to me that you are uncomfortable with incremental progress.
Not true.
>
> > But never mind.
>
> In what way does throwing your hands up in the air get us closer to a
> resolution? Should we read that message as indication that you're no
> longer going to be participating?
I do not want to get involved in controversy. Nor do I want to get any
more *where is your code* stuff.
I have been asked a lot of detailed questions by people. I respect
that process. The reason I buy into it
is that Habari has shown the ability to reach very difficult even
ground breaking decisions once the right info is supplied and the case
is fully argued. But it is tough to do when people refer to technical
response as *criticism* of other people's work.
I do criticise Blueprint or its authors for this reason: It sets out
to do something which is very difficult and hitherto regarded as
impossible. That is a fun challenge. It will be welcomed by many
people. But it is going to involve
some huge corner cutting and compromise. Call me old fashioned. But I
am a hand roller.
Buttoning down specs (and tools / libs) is not a coding issue. It is a
dialogue / community issue to do with informed decision making. That
requires dialogue.
>
> Are you going to put forward any positive suggestions? Are you going to
> put forward working examples of the kind of CSS you'd like to see? Are
> you going to put forward any template files for consideration?
Yes I am. Once the necessary spec is buttoned down. Do I want to code
admin against a moving indefined target?
No - not if I can avoid it.
Root
A lot of this has been addressed in other threads.
Where I take issue is in the belief that there is something
inherently flexible in Blueprint which would not be the case somehow
in house.
The inhouse CSS would be as flexible as anybody wanted / needed.
And could give a platform to in house html / php coders.
On Aug 31, 6:22 pm, "Owen Winkler" <epit...@gmail.com> wrote:
I do not with respect think I have understood the blueprint user group
at all.
On large sites - by which I mean sites where mark up is being
contributed by multiple authors
a common css framework is very handy.
The big audience if for the graphics designers would be coders who are
as frustrated as heck
at their inability to get anything done because of the peculiarities
in CSS. I have some sympathy for them.
But like all tools it brings limitations with it. And the more I look
at Blueprint the less I like it
and the the less suitable I think it is for any part of habari.
Attaching margins to fixed width floating elements? No thanks. Using
padding as a positioning tool . Whooa there cowboy. Negative margin
positioning? Hang on just one second. Clearfix? No way. Fonts in
pixels? This is not 1990. Eric Meyers global reset? Cool. But not as
cool as Andrew Krepanis' reset. So what are we left with thats useful?
Zilch. And a lot of bitching.
> http://groups.google.com/group/habari-dev/browse_thread/thread/2b53c5...
Root
Scott Merrill
> On Sep 2, 1:24 am, Scott Merrill <ski...@skippy.net> wrote:
>> Are you suggesting that no work at all can be put forth toward the admin
>> interface until we decide whether Javascript is a requirement?
>>
> Pretty much so yes. I am saying that specification needs to precede
> coding. I wouldn't actually want to stop anyone in their tracks even
> if I could.
> But I would advocate bumping the spec rapidly up the must do list. On
> JS.
> And on legacy browser support.
For the benefit of this conversation, please define what you mean by
"legacy" browser?
I only use Firefox on GNU/Linux, so I'm not personally concerned about
how well other browsers work.
> If you were in absolutely charge of the project, what decision would
> you
>> make with respect to Javascript as a requirement? Why would you make
>> that decision? What documentation can you provide to back up your decision?
>>
> If I was in charge I would set out on the basis that JS was not going
> to be used.
> I would wait for any specific proposal to use JS for a specific
> function to come forward
> and then I would examine it very closely on its merits. I would not
> preempt any choice that would be made then.
> But in general I am not in favour of ajaxified sliding doodads from
> hell.
Straw man argument. Yes, AJAX and Javascript can be used to make
sliding doodads, but they can also be used to streamline interaction
with the software.
We would like to have a smooth installation process, with errors
reported to the user before they click the "Submit" button. That will
require some AJAX, as I understand it. Using that as a starting point,
I think it's fair to require Javascript within the administrative interface.
> Given that you're not in absolutely control of the project, what is
> your
>> preference? What compromises do you feel are acceptable, if any?
>>
>
> I start from a perspective of standards. If it runs in a browser it
> should follow them.
> BUT:
> We are designing an application. Certain criteria need to be met to
> operate the software eg php 5.
> Are there really guys who want to use bleeding edge software like
> Habari but who still use Netscape 4?
> I doubt it? Should we worry if they do? Prolly not. But I hate JS. The
> reason I hate it is that I encounter so
> many scripts which are badly written that my system freeezes and or
> crashes. And that is FF on linux. Regularly. So speaking personally I
> browse with JS off by default. Is that a good compromise for Habari?
> Prolly not. I am open minded. What I am advocating is getting it clear
> before we start. Perfect world? JS has an on / off switch in options
> or something.
What are your thoughts on my previous suggestion of requiring Javascript
for the primary browser-based administrative interface, while also
providing an interface friendly to mobile browsers? It is my vision
that this mobile version would be free of Javascript, and as fully
functional as we can reasonably make it.
I admit, though, that the idea of having two distinct admin interfaces,
and coding and supporting each, is not terribly appealing.
>>> This is ass backwards.
>> In what way is this ass backwards? In what way does calling it ass
>> backwards get us closer to a solution?
>>
>
>
> Ass backwards is I understand a widely used colloquial expression
> which emanates from the US.:)
> It quite neatly encapsulates the difficulty of writing a programme
> without a technical specification in place.
> This has historically been a weakness on other platforms. I hope we do
> better. Lit majors versed in Shakespeare,
> prolly still call it putting the cart before the horse or some such :)
'Ass backwards' also has implications of incompetence. It's a strongly
derogatory expression.
Yes, lack of specification is something that has hindered other tools.
I would like to avoid that for Habari, as well.
> I am itching to get started. I am not going to until the spec is
> buttoned down.
> And nor am I going to start if we go with Blueprint.css. Some folk
> here
> might think that would be a good thing. :)
What's stopping you from preparing a demonstration of your ideal admin
interface? No Javascript, no Blueprint; just those items you deem
appropriate based on your expertise. Such a working prototype would be
well received, and serve as an excellent starting-off point for
additional revision.
The expression "working code, rough consensus" is the catchphrase we
pursue. In the absence of a better solution presented to us, the
working code that we have is something we'll use. If better code is
presented, why would it not be used?
> Not true.
>>> But never mind.
>> In what way does throwing your hands up in the air get us closer to a
>> resolution? Should we read that message as indication that you're no
>> longer going to be participating?
>
> I do not want to get involved in controversy. Nor do I want to get any
> more *where is your code* stuff.
> I have been asked a lot of detailed questions by people. I respect
> that process. The reason I buy into it
> is that Habari has shown the ability to reach very difficult even
> ground breaking decisions once the right info is supplied and the case
> is fully argued. But it is tough to do when people refer to technical
> response as *criticism* of other people's work.
Email is a less-than-perfect medium for some of the conversations we
must have. We can all improve the process by speaking clearly, in full
sentences. Refrain from emotionally charged expressions. Provide
documented counter-examples if you're going to advocate against
something. Listen carefully to the criticisms of others. Try to ignore
any perceived personal insults, and focus instead on the technical
issues raised.
Sean T Evans
> For the benefit of this conversation, please define what you mean by
> "legacy" browser?
>
> I only use Firefox on GNU/Linux, so I'm not personally concerned about
> how well other browsers work.
>
At work, I'm forced to use what I'm given. Which at this time (and for
the foreseeable future) is (a buggy install of) IE6 at 600x800 on
Windows XP. I'm willing to bet that when we start releasing to the
public at large, I won't be the one with the least compatible system. As
much as the AJAX and stuff looks cool, I would like to suggest that we
don't make our systems dependent on it.
Like you Skippy, I'm a healthy, fully sighted, English speaking,
technically proficient tinkerer. I keep my own systems up to date, and
employ many of the latest features. However, I firmly believe that we
need to make sure that in the end, you actually _can_ use habari in
lynx. It may not be nearly as pretty or intuitive, but I think it needs
to at least basic functionality in such a case. (We should also make
sure that all of the themes we ship with the package, or plugins that
default to "on" meet this requirement as well.) I'll continue to argue
for this aspect as long as my grandmother is using WebTV.
As I understand it, one of the primary reasons for separating content
from format is to insure that your content is still usable _without_ the
formatting.
I think this entire discussion brings to light a need to start looking
at a more formal structure for some of the things we are doing. We make
many decisions on IRC. This has great advantages to Habari, in that it
makes us very agile, problems are solved quickly, because we are able to
have several people work on a problem at the same time. Decisions are
also made very quickly. Allowing people to not halt work for hours, or
days, waiting for an answer to a question. However there are 16 people
in the IRC channel at this time. There are rarely more than 30. There
are currently 276 people subscribed to this mailing list. That leaves a
huge chunk of the Habari Community out of these discussions. When a
subject like this becomes a major sticking point, we need a way to more
formally review the discussion and put it to a community vote. I think
it's also time to formalize the voting structure, so that as a
community, when a decision is made, the reason for that decision is
clear. None of us, particularly the founders I believe, want anyone in
the Habari Community to feel that a decision has been made because
"That's the way the founders said it's going to be." If we can solve
these questions now, as more people join the project they will see that
we actually practice the meritocracy and openness that we claim we
believe in so fundamentally.
I propose a wiki page spelling out what the founders, members, and
community feel is the best way to insure that A) decisions are clear and
open and B) the project doesn't become stagnant because every decision
must wait for a vote of the entire community.
The... vibrancy... of this discussion is actually, in my opinion, a good
sign for Habari. We're able to discuss, with relatively little emotion,
points of view that clearly don't match our own and (for the most part)
keep on the topic at hand. This is why I'm proud to be a part of this
project.
Owen Winkler
>
> Scott Merrill wrote:
> > For the benefit of this conversation, please define what you mean by
> > "legacy" browser?
> >
> > I only use Firefox on GNU/Linux, so I'm not personally concerned about
> > how well other browsers work.
> >
>
> At work, I'm forced to use what I'm given. Which at this time (and for
> the foreseeable future) is (a buggy install of) IE6 at 600x800 on
> Windows XP.
I would bet that this is the more prevalent case, and explains why IE
has such a large market share (beyond it coming with most desktop
PCs). I think this is one area of Habari where "I use X, so I don't
care about Y" does not float.
Rather than say we need to be universally compatible with anything,
lets choose some browsers of note. Let's figure out a way we can
decide whether Lynx is something we should support. I think metrics
would suggest that we should not support Lynx. I wonder how many
people are actually using WebTVs to access their blogging admin. I
really can't imagine that you would both run a blog and still use a
WebTV.
Mind you, this is relevant to the admin *only*, because as you point
out, the presentation is separate from the content in the case of the
output. If you really want to support Lynx, then there can be a theme
that supports Lynx. The real question is what browsers the admin will
support, since admin themes are not on the schedule at this time.
> I think this entire discussion brings to light a need to start looking
> at a more formal structure for some of the things we are doing. We make
> many decisions on IRC. This has great advantages to Habari, in that it
> makes us very agile, problems are solved quickly, because we are able to
> have several people work on a problem at the same time. Decisions are
> also made very quickly.
No formal decisions are ever made on IRC. Decisions may be made on
IRC, but they are not formal. This has always been the case.
I think the process we have has been working, even if the process
isn't as obvious as it could be. I think we need not discuss every
little decision, and the peer review that takes place when code
changes is usually enough to spawn a mailing list thread when
something looks odd.
When people are thinking about introducing changes that might be
controversial or require explanation, they usually send something to
the list first, and I think that's perhaps what set off this whole
Blueprint CSS thread: I think Khaled did not consider using Blueprint
controversial when he comitted it, and then people lashed out because
they had a different perception.
I think the review process is working correctly, but had the reactions
been a bit more reasoned and constructive, we would have had less
turmoil over the issue.
Outlining our process might be helpful in the long term. In the short
term, I would like to get constructive on the admin CSS issue.
Owen
Root
On Sep 2, 2:01 pm, Scott Merrill <ski...@skippy.net> wrote:
> Root wrote:
> > On Sep 2, 1:24 am, Scott Merrill <ski...@skippy.net> wrote:
>
> I only use Firefox on GNU/Linux, so I'm not personally concerned about
> how well other browsers work.
>
That pretty much sums it all up.
Root
I haven't seen anybody lash out in this thread. I have seen a vibrant
constructive
discussion. The issue it turns out now does not seem to be Blueprint
at all.
The issue is what is the technical specification for admin expressed
in terms of accessibility and useability including but not exclusively
browser support and a policy statement on JS.
The CSS wherever it comes from can only help deliver or maybe
inadvertently hinder that process.
Andrew da Silva
Blueprint framework.
Scott initiated talks about what should be the requirements for admin,
your opinions?
-1 blueprint
-1 javascript
+1 themeable admin
We don't necessarily need a CSS framework, we just have to build a
good CSS base structure and go from there.
And again, I can't stress it enough to conform with accessibility laws
regarding forms and such.
Root
Owen Winkler
>
> Ok One more go at this:
> I haven't seen anybody lash out in this thread. I have seen a vibrant
> constructive
> discussion.
This discussion has been anything but constructive, especially when
including your message prior to the one quoted.
There is no point in voting down Blueprint if there's nothing to
replace it. If "custom CSS for Habari's admin" is the replacement,
then please provide it. We can't very well rip out Blueprint without
putting something there that does what it is currently doing.
This is very much the case of "put up or shut up". Nobody is going to
appoint anyone to construct anything. You need to take it and own it
- this is what Khaled did by integrating Blueprint. Assuming anyone
agrees with removing Blueprint, what is the plan to replace it? When
are you going to provide that contribution? Until that time happens,
I think I can safely ignore this thread.
There hasn't been adequate discussion about requiring javascript in
the admin to bring it to vote.
There hasn't even been a word about theming the admin, which - even if
that is something worth pursuing - is not something that we should
consider right now if the future of the admin design/layout is in the
air.
Bringing any of this to a vote at this point is premature.
Owen
Root
the
admin area and takes ownership of all the issues that follow is not -
presumably -
going to be required to follow anybody elses graphics and all the
useability , accessibilty and coding issues therein are they? It would
need a clean sheet.
And I do not agree that blueprint specifically needs anything to
replace it to vote against it.
The vote is against bad CSS and for custom CSS.
Seems plain enough.
On Sep 2, 6:04 pm, "Owen Winkler" <epit...@gmail.com> wrote:
Doug Stewart
> Seems plain enough.
Criminey. What part of "put up or shut up" is so hard to understand?
The vote is not as you describe it; rather , it is a vote for a
working, if flawed and incomplete CSS setup vs. an unseen, unproven
and thus far vapor custom solution.
+1 to keeping it right where it is until something better is
demonstrated. Ooh-rah, open source!
--
-Doug
khaled Abou Alfa
I'm an engineer by profession, so I lament the amount of time we spend in meetings talking about building something rather than getting around to the fact and doing it. Take some time and edit a css file, you already know what it's supposed to look like, you're just not ok with how it's currently being done. No worries at all, give me that alternative. Show me why the alternative is better. It's not going to be lost work at all. Why would anyone say no to something that is better? I know how quickly you work, it would take you all of an evening to pull it together and just do it.
C'mon :).
Root
minutes ago
when out of left field it turned turtle. You might think some people
would be
grateful that someone pointed that out, offered to fix it, and
explained what was necessary to proceed
in terms of the decision making flow chart. I am obviously in the
wrong.
Have a nice day,
On Sep 2, 6:31 pm, "Doug Stewart" <zamo...@gmail.com> wrote:
Doug Stewart
> minutes ago
> when out of left field it turned turtle. You might think some people
> would be
> grateful that someone pointed that out, offered to fix it, and
> explained what was necessary to proceed
> in terms of the decision making flow chart. I am obviously in the
> wrong.
> Have a nice day,
>
There's a saying that has floated around the RedHat/Fedora mailing
lists for years: "If it isn't in Bugzilla, it doesn't exist", meaning
that you can point out bugs, offer solutions, post code, etc., but
unless someone files a bug, said bugs, solutions, code, etc. doesn't
exist insofar as the project is concerned.
For an ostensible "professional", you have consistently offered little
more than vitriol and are easily offended, while you offer few real
solutions and code. If this is such a huge issue, whip up a quick
.css file, create a Google Code ticket with the code as an attachment
and then we can take an unbiased look at the "Blueprint vs. CSS X"
issue. Until then, it's no choice at all.
I'm not decrying advocating passionately for an issue you care about,
I'm decrying _carping on endlessly_ about it -- the Open Source
equivalent of Ron Paul supporters, you might say. *grin*
And, once you've put up the code, it will be time for ME to either put
up or shut up. Wonderful the way that works. *chuckle*
--
-Doug
Root
On Sep 2, 6:57 pm, "Doug Stewart" <zamo...@gmail.com> wrote:
Geoffrey Sneddon
On 2 Sep 2007, at 15:05, Sean T Evans wrote:
> However, I firmly believe that we
> need to make sure that in the end, you actually _can_ use habari in
> lynx. It may not be nearly as pretty or intuitive, but I think it
> needs
> to at least basic functionality in such a case. (We should also make
> sure that all of the themes we ship with the package, or plugins that
> default to "on" meet this requirement as well.) I'll continue to argue
> for this aspect as long as my grandmother is using WebTV.
Not only do we need to work with Lynx, but we need to work with
screen-readers such as JAWS (the latest version currently works on
top of IE6).
- Geoffrey Sneddon
Owen Winkler
>
> Not only do we need to work with Lynx, but we need to work with
> screen-readers such as JAWS (the latest version currently works on
> top of IE6).
We should try to support screen readers, but what is the point of
supporting Lynx? (If there really is one, I'd like to hear it -
probably something I've overlooked.)
Better questions might be by what criteria can we determine what
browsers we must support? Which browsers are those? To what degree
do we support them?
Let's make a chart on the wiki!
Owen
Geoffrey Sneddon
On 2 Sep 2007, at 22:33, Owen Winkler wrote:
>
> On 9/2/07, Geoffrey Sneddon <fooli...@googlemail.com> wrote:
>>
>> Not only do we need to work with Lynx, but we need to work with
>> screen-readers such as JAWS (the latest version currently works on
>> top of IE6).
>
> We should try to support screen readers, but what is the point of
> supporting Lynx? (If there really is one, I'd like to hear it -
> probably something I've overlooked.)
Lynx is really the the de-facto minimalist browser, supporting no
frames, no styling, nothing apart from basic HTML. It has its uses
(such as when you need a CLI browser).
> Better questions might be by what criteria can we determine what
> browsers we must support? Which browsers are those? To what degree
> do we support them?
We must have full functionality in all UAs. That doesn't, however,
mean we can't use AJAX because not every UA supports it, as long as
we provide the functionality in another way. As far as having the
full UI, I'd say IE6+, Fx2+, and Saf2+.
- Geoffrey Sneddon
Owen Winkler
http://developer.yahoo.com/yui/articles/gbs/
Owen
Root
Yahoo grades Class C as *unsupported*.
That is pretty categoric.
Do you want to cut off legacy browsers like that?
And Geoffrey: Welcome back. We need you now. :)
Rich Bowen
Well obviously there is no point in moving forward on admin at alluntil the specification for Javascriptand the browsers is buttoned down. Those things determine how it needs
to be coded. This is ass backwards.